<AWT Dev> [8] Review request for CR 8006406: lightweight embedding in other Java UI toolkits

Anton V. Tarasov anton.tarasov at oracle.com
Fri Feb 8 06:09:12 PST 2013


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.

> 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