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

[Philip Race]

Hi,

Are you sure this is all the files ? 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.

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


  290      * creates with matching platform information.

creates -> created

296      * Moves and resize the embedded frame.

Either
moves -> move
or
resize -> resizes

ie it should be either "move and resize", or "moves and resizes"

* setLocation() and setBounds() for EmbeddedFrame really don't move it

could we spell out java.awt.Component.setLocation() and java.awt.Component.setBounds()
so it is clear what methods are meant.

  304      * within the native parent. These methods always put embedded frame to

put embedded frame to ->  locate the embedded frame at

  305      * (0, 0) for backward compatibility. To allow moving embedded frames
  306      * this method was introduced, and it work just the same way as

work ->  works

  307      * setLocation() and setBounds() for usual, non-embedded components.


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

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 ?

Synthesize native message  to activate or deactivate EmbeddedFrame
           ^                                        ^
           a                                        an



-phil.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160801/8c7f332d/attachment.html>