<AWT Dev>  Review request for CR 8006406: lightweight embedding in other Java UI toolkits
victor.dyakov at oracle.com
Fri Feb 8 06:30:01 PST 2013
On 08.02.2013 18:09, Anton V. Tarasov wrote:
> Hi Sergey,
> On 08.02.2013 17:46, Sergey Bylokhov wrote:
>> Hi, Anton.
>> Who will create tests for this feature?
> I know that QA guys will definitely address it.
Did you communicate it to someone in SQE? Did you have commitment?
>> Is it possible to add at least 1 simple test to regression ws?
> It's possible I think, but... taking into account some load with it
> (I'm to complete and submit the fx part shortly), I'd prefer to put it
> to a separate task.
> I have some local testcase (swingset2 embedded into javafx stage), but
> it's not in the form of a reg test.
>> 08.02.2013 21:27, Anton V. Tarasov wrote:
>>> Hi All,
>>> Please, review the changes for the CR:
>>> webrev: http://cr.openjdk.java.net/~ant/8006406/webrev.6
>>> It introduces sun.swing.JLightweightFrame class, aimed at
>>> lightweight embedding of Swing components into java-based toolkits.
>>> The primary target is JavaFX toolkit, however the class is not
>>> limited to this usage and the API it provides is quite generic.
>>> Below I'm giving a link to the jfx side implementation. This
>>> implementation should not be reviewed in this thread (it is in a
>>> pre-review phase),
>>> it should just clarify how the introduced API is supposed to be
>>> used. Namely, SwingNode.SwingNodeContent which implements
>>> sun.swing.LightweightContent and forwards requests from
>>> sun.swing.JLightweightFrame to NGExternalNode which does the rendering.
>>> webrev: http://cr.openjdk.java.net/~ant/RT-27887/webrev.1
>>> Some comments on the awt/swing part:
>>> - Only Win and Mac implementation is currently available, X11 will
>>> come lately.
>>> - Win implementation uses a heavyweight window behind the
>>> lightweight frame, while it is not actually needed for lightweight
>>> This is due to the architecture of the Win AWT peers which are
>>> strongly tight to the native code, and it's not a trivial task to
>>> separate them.
>>> On Mac the lightweight frame peer is truly lightweight, meaning
>>> that it doesn't create an NSWindow object behind it. The Mac port LW
>>> allows to override and substitute CPlatform* classes with their
>>> lightweight stubs.
>>> - LightweightFrame, among others, introduces two new methods -
>>> grabFocus() and ungrabFocus(boolean). Ideally, these methods should
>>> go to
>>> the super Window class where the grab API becomes public (which
>>> is a long-term project...). Current host of the grab API is
>>> SunToolkit, which
>>> now forwards the calls to LightweightFrame. This is necessary to
>>> intercommunicate with the client when grab/ungrab happens on both
>>> - Unresolved issues exist, like modal dialogs, d&d etc. They are to
>>> be addressed further.
More information about the awt-dev