<AWT Dev> [8] Review request for CR 8006406: lightweight embedding in other Java UI toolkits
Victor Dyakov
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.
Anton,
Did you communicate it to someone in SQE? Did you have commitment?
Thanks,
Victor
>
>> 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.
>
> Thanks,
> Anton.
>
>>
>> 08.02.2013 21:27, Anton V. Tarasov wrote:
>>> Hi All,
>>>
>>> Please, review the changes for the CR:
>>> http://bugs.sun.com/view_bug.do?bug_id=8006406
>>>
>>> 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
>>> embedding.
>>> 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
>>> abstraction
>>> 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
>>> sides.
>>>
>>> - Unresolved issues exist, like modal dialogs, d&d etc. They are to
>>> be addressed further.
>>>
>>> Thanks,
>>> Anton.
>>>
>>
>>
>
More information about the awt-dev
mailing list