<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