<AWT Dev> [9] Review Request: 8148109 [SWT] Provide a supported mechanism to use EmbeddedFrame

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Aug 2 14:29:41 UTC 2016


Hello,
Here is the new version
http://cr.openjdk.java.net/~serb/8148109/webrev.01

The spec is updated, JAWT_VERSION_9 was changed to 0x00090000.

Some notes inline:

On 01.08.16 16:19, Philip Race wrote:
> Hi, Are you sure this is all the files ?

Everything which should be changed to provide an access to our existed 
API, current fix is just a proxy. If some bugs will be found after that 
then the java side should be changed.

> Seems like I should be seeing some implementation of this on the Java side. General question: What is
> the coordinate system for x/y/w/h on a 'hi-dpi' configuration ? Can we
> add a note somewhere about this.

This is a good question, I'll investigate this since the same notes 
should be done for old jawt api as well.

> The alignment looks off in mapfile-mawt-vers and mapfile-vers-linux

Our mapfiles mix tabs and spaces for alignment. I guess we should change 
this to use one style only.

> I presume a typical usage of this method will be to resize the embedded
> frame if the native container is re-sized?

Yes, typically an EmbeddedFrame is located at 0.0 in the container and 
changes only the sizes.

>
> Should there be an additional note here about who's responsibility it is
> to track resize on the native container  and then call this method ?

I am not sure that it is necessary to add a notes about the native 
container of the EmbeddedFrame, the assumption is that this method 
should be called then necessary to change the size of our frame, like 
existed setBounds/setSize/setLocation.

> On 8/1/16, 5:39 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk9.
>>
>> In the fix the part of our internal api is opened via jawt library
>> which is a jdk api, so the important part of the fix is in the jawt.h
>> file. This api can be used by other toolkits to implement embedding of
>> awt/swing components into some other native windows.
>>
>> There are no tests in the fix since I plan to implement a number of
>> tests via separate CR.(but I am not sure what is the best way to
>> create a native dll, which will reuse jawt api -> manual/precompiled
>> dll/ compilation on the fly?).
>>
>> jprt job is passed, the ccc will be filed after the technical review.
>>
>>  - JAWT_VERSION_9 is used intentionally instead of JAWT_VERSION_1_9.
>>  - On OSX validateWithBounds() intentionally was changed to
>> setBoundsPrivate() as on other platforms.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148109
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8148109/webrev.00
>>


-- 
Best regards, Sergey.


More information about the awt-dev mailing list