Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

Seems a reasonable addition to me, too.

-- Kevin


Michael Ennen wrote:

Sounds like a reasonable idea to me.

On Mon, Mar 26, 2018 at 1:00 PM, Nir Lisker  wrote:

  

I'm thinking about the addition of a public method for mouse click, which
is mouse press and then mouse release - the parallel for key typed. Is it
worth?

- Nir

On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:



Seems good to me, too.

-- Kevin


Michael Ennen wrote:

  

Sounds like a good idea to me to only have `getScreenCapture` methods
that have a WritableImage parameter which can be `null` which means a
new WritableImage will be created otherwise the given one is re-used, as
in Scene.snapshot and Node.snapshot. What are your thoughts on this,
Kevin?

On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer > wrote:



On Mar 23, 2018, at 5:50 PM, Michael Ennen > wrote:

Kevin,

I believe I followed all of your suggestions, except the one with a
re-usable WritableImage.
If you want me to implement that as well, I can, but you seemed
unsure
about the necessity
of it.

  

I think it should be included to reduce garbage generated in a
case where repeated captures is used.  Such as a desktop sharing
application, a screen recorder, etc.
It would also be consistent with the node.snapshot API.

In fact, I would just have the version that takes a WriteableImage
and match the behaviour of node.snapshot.

Scott




--
Michael Ennen





  

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Sounds like a reasonable idea to me.

On Mon, Mar 26, 2018 at 1:00 PM, Nir Lisker  wrote:

> I'm thinking about the addition of a public method for mouse click, which
> is mouse press and then mouse release - the parallel for key typed. Is it
> worth?
>
> - Nir
>
> On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Seems good to me, too.
>>
>> -- Kevin
>>
>>
>> Michael Ennen wrote:
>>
>>> Sounds like a good idea to me to only have `getScreenCapture` methods
>>> that have a WritableImage parameter which can be `null` which means a
>>> new WritableImage will be created otherwise the given one is re-used, as
>>> in Scene.snapshot and Node.snapshot. What are your thoughts on this,
>>> Kevin?
>>>
>>> On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer >> > wrote:
>>>
>>>
>>>
>>> On Mar 23, 2018, at 5:50 PM, Michael Ennen > wrote:

 Kevin,

 I believe I followed all of your suggestions, except the one with a
 re-usable WritableImage.
 If you want me to implement that as well, I can, but you seemed
 unsure
 about the necessity
 of it.

>>>
>>> I think it should be included to reduce garbage generated in a
>>> case where repeated captures is used.  Such as a desktop sharing
>>> application, a screen recorder, etc.
>>> It would also be consistent with the node.snapshot API.
>>>
>>> In fact, I would just have the version that takes a WriteableImage
>>> and match the behaviour of node.snapshot.
>>>
>>> Scott
>>>
>>>
>>>
>>>
>>> --
>>> Michael Ennen
>>>
>>
>


-- 
Michael Ennen

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Nir Lisker]

I'm thinking about the addition of a public method for mouse click, which
is mouse press and then mouse release - the parallel for key typed. Is it
worth?

- Nir

On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth  wrote:

> Seems good to me, too.
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
>> Sounds like a good idea to me to only have `getScreenCapture` methods
>> that have a WritableImage parameter which can be `null` which means a
>> new WritableImage will be created otherwise the given one is re-used, as
>> in Scene.snapshot and Node.snapshot. What are your thoughts on this,
>> Kevin?
>>
>> On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer > > wrote:
>>
>>
>>
>> On Mar 23, 2018, at 5:50 PM, Michael Ennen >> > wrote:
>>>
>>> Kevin,
>>>
>>> I believe I followed all of your suggestions, except the one with a
>>> re-usable WritableImage.
>>> If you want me to implement that as well, I can, but you seemed
>>> unsure
>>> about the necessity
>>> of it.
>>>
>>
>> I think it should be included to reduce garbage generated in a
>> case where repeated captures is used.  Such as a desktop sharing
>> application, a screen recorder, etc.
>> It would also be consistent with the node.snapshot API.
>>
>> In fact, I would just have the version that takes a WriteableImage
>> and match the behaviour of node.snapshot.
>>
>> Scott
>>
>>
>>
>>
>> --
>> Michael Ennen
>>
>

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

Seems good to me, too.

-- Kevin


Michael Ennen wrote:

Sounds like a good idea to me to only have `getScreenCapture` methods
that have a WritableImage parameter which can be `null` which means a
new WritableImage will be created otherwise the given one is re-used, as
in Scene.snapshot and Node.snapshot. What are your thoughts on this,
Kevin?

On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer > wrote:





On Mar 23, 2018, at 5:50 PM, Michael Ennen > wrote:

Kevin,

I believe I followed all of your suggestions, except the one with a
re-usable WritableImage.
If you want me to implement that as well, I can, but you seemed
unsure
about the necessity
of it.


I think it should be included to reduce garbage generated in a
case where repeated captures is used.  Such as a desktop sharing
application, a screen recorder, etc.
It would also be consistent with the node.snapshot API.

In fact, I would just have the version that takes a WriteableImage
and match the behaviour of node.snapshot.

Scott




--
Michael Ennen

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Sounds like a good idea to me to only have `getScreenCapture` methods
that have a WritableImage parameter which can be `null` which means a
new WritableImage will be created otherwise the given one is re-used, as
in Scene.snapshot and Node.snapshot. What are your thoughts on this,
Kevin?

On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer  wrote:

>
>
> On Mar 23, 2018, at 5:50 PM, Michael Ennen  wrote:
>
> Kevin,
>
> I believe I followed all of your suggestions, except the one with a
> re-usable WritableImage.
> If you want me to implement that as well, I can, but you seemed unsure
> about the necessity
> of it.
>
>
> I think it should be included to reduce garbage generated in a case where
> repeated captures is used.  Such as a desktop sharing application, a screen
> recorder, etc.
> It would also be consistent with the node.snapshot API.
>
> In fact, I would just have the version that takes a WriteableImage and
> match the behaviour of node.snapshot.
>
> Scott
>
>


-- 
Michael Ennen

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Scott Palmer]

> On Mar 23, 2018, at 5:50 PM, Michael Ennen  wrote:
> 
> Kevin,
> 
> I believe I followed all of your suggestions, except the one with a
> re-usable WritableImage.
> If you want me to implement that as well, I can, but you seemed unsure
> about the necessity
> of it.

I think it should be included to reduce garbage generated in a case where 
repeated captures is used.  Such as a desktop sharing application, a screen 
recorder, etc.
It would also be consistent with the node.snapshot API.

In fact, I would just have the version that takes a WriteableImage and match 
the behaviour of node.snapshot.

Scott

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Kevin,

I believe I followed all of your suggestions, except the one with a
re-usable WritableImage.
If you want me to implement that as well, I can, but you seemed unsure
about the necessity
of it.

Hopefully it is easy for you to review using the GitHub PR:
https://github.com/javafxports/openjdk-jfx/pull/36
as it takes less effort for me as the manual process of converting to a hg
patch and importing it to generate
a webrev is somewhat laborious.

Once you approve the changes I can of course generate a hg patch, commit,
and webrev.

Since you suggested the params to be doubles I took the initiative and
changed the params
"down the line" to the native API calls, where appropriate. What I mean is,
take the Mac
GlassRobot.m implementation, the native `_mouseMove` implementation uses
`CGEventCreateMouseEvent`
which expects a CGPoint for the (x,y) location, which uses floats. So in
this case the doubles
are "down-casted" to floats to interact the native API, and then
"up-casted" to doubles when
returned by the public Robot class.

For other native API implementations the double params are "down-casted"
all the way to
ints if that's what the native API expects in the following sense:

 (starts as double)  --> Downcasted to what the native API wants
(sometimes int, sometimes float)
 | <-- Always upcasted to double as that's
what public Robot API uses
public Robot class <-> private GlassRobot <-> platform-specific Java class
(e.g. MacRobot.java) <-> native implementation (e.g. MacRobot.m)

This way the values returned by, for example, getMouseX and getMouseY, more
closely
match the actual values of the system, and the double params given to, for
example, mouseMove,
are used to provide better accuracy when the native API supports it, but if
not, the double
is simply casted to an int the extra precision does nothing. In other
words, calling robot.mouseMove(75.5, 75.5)
will try and pass the extra accuracy along to the native API if it expects
it, but if not, won't.

Hopefully that makes sense.

Thanks!

On Thu, Mar 22, 2018 at 5:54 AM, Kevin Rushforth  wrote:

>
>
> Michael Ennen wrote:
>
> Quick question:
>
> Currently a Robot is created by calling `Application.createRobot` which
> delegates
> to the underlying platform-specific application class (GtkApplication,
> WinApplication, etc.)
> via `com.sun.glass.ui.Application.GetApplication().createRobot();`
>
>
> I just meant that the Toolkit class was a convenient place to call
> com.sun.glass.ui.Application.GetApplication().createRobot() -- something
> like this:
>
> Toolkit:
>
> public GlassRobot createRobot() {   // or could be abstract
> throw new UnsupportedOperationException("not implemented");
> }
>
> QuantumToolkit:
>
> public GlassRobot createRobot() {
> return com.sun.glass.ui.Application.GetApplication().createRobot();
> }
>
> The reason for doing it there is because it already has the mechanism for
> handling QuantumToolkit versus StubToolkit. Otherwise you wouldn't need the
> extra level of indirection.
>
> -- Kevin
>
>
> You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, etc.
> all extend
> the abstract base class GlassRobot (the peer), how will Toolkit be able to
> instantiate
> the correct, platform-specific class? Sorry, I got stuck trying to
> implement this part
> of your review. The rest is easy for me to follow and will be no problem.
>
>
> On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Hi Michael,
>>
>> Here is some quick feedback.
>>
>> I think what you have is heading in the right direction as far as the
>> public API goes. I'd like to get some feedback from other developers as
>> well. I would want to make sure that the API meets the needs of multiple
>> developers.
>>
>> I took a look at the public class and as I may have mentioned earlier, it
>> will help to split the API and the implementation even further, by creating
>> a peer object as we do for Scene, Stage, etc., rather than having the glass
>> platform implementation directly subclass the public Robot class.
>>
>> Then you can easily delegate to the Glass Robot peer without having any
>> implementation leak into the public API (e.g., the overridden create and
>> dispose methods).
>>
>> So what you would have in that case is something more like this:
>>
>> public final class Robot {
>>
>> private final GlassRobot peer;
>>
>> public Robot() {
>> // Ensure we have proper permission for creating a robot.
>> final SecurityManager sm = System.getSecurityManager();
>> if (sm != null) {
>> sm.checkPermission(CREATE_ROBOT_PERMISSION);
>> }
>>
>> Application.checkEventThread();
>>
>> peer = Toolkit.createRobot();
>> }
>>
>> // NOTE: for the rest, the peer can do the thread check
>>
>> public void keyPress(KeyCode keyCode) {
>> peer.keyPress(keyCode);
>> }
>>
>> 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Got it. Not sure why I made it so complicated in my head, lol.

Will be working on this in the next few days.

On Thu, Mar 22, 2018 at 5:54 AM, Kevin Rushforth  wrote:

>
>
> Michael Ennen wrote:
>
> Quick question:
>
> Currently a Robot is created by calling `Application.createRobot` which
> delegates
> to the underlying platform-specific application class (GtkApplication,
> WinApplication, etc.)
> via `com.sun.glass.ui.Application.GetApplication().createRobot();`
>
>
> I just meant that the Toolkit class was a convenient place to call
> com.sun.glass.ui.Application.GetApplication().createRobot() -- something
> like this:
>
> Toolkit:
>
> public GlassRobot createRobot() {   // or could be abstract
> throw new UnsupportedOperationException("not implemented");
> }
>
> QuantumToolkit:
>
> public GlassRobot createRobot() {
> return com.sun.glass.ui.Application.GetApplication().createRobot();
> }
>
> The reason for doing it there is because it already has the mechanism for
> handling QuantumToolkit versus StubToolkit. Otherwise you wouldn't need the
> extra level of indirection.
>
> -- Kevin
>
>
> You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, etc.
> all extend
> the abstract base class GlassRobot (the peer), how will Toolkit be able to
> instantiate
> the correct, platform-specific class? Sorry, I got stuck trying to
> implement this part
> of your review. The rest is easy for me to follow and will be no problem.
>
>
> On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Hi Michael,
>>
>> Here is some quick feedback.
>>
>> I think what you have is heading in the right direction as far as the
>> public API goes. I'd like to get some feedback from other developers as
>> well. I would want to make sure that the API meets the needs of multiple
>> developers.
>>
>> I took a look at the public class and as I may have mentioned earlier, it
>> will help to split the API and the implementation even further, by creating
>> a peer object as we do for Scene, Stage, etc., rather than having the glass
>> platform implementation directly subclass the public Robot class.
>>
>> Then you can easily delegate to the Glass Robot peer without having any
>> implementation leak into the public API (e.g., the overridden create and
>> dispose methods).
>>
>> So what you would have in that case is something more like this:
>>
>> public final class Robot {
>>
>> private final GlassRobot peer;
>>
>> public Robot() {
>> // Ensure we have proper permission for creating a robot.
>> final SecurityManager sm = System.getSecurityManager();
>> if (sm != null) {
>> sm.checkPermission(CREATE_ROBOT_PERMISSION);
>> }
>>
>> Application.checkEventThread();
>>
>> peer = Toolkit.createRobot();
>> }
>>
>> // NOTE: for the rest, the peer can do the thread check
>>
>> public void keyPress(KeyCode keyCode) {
>> peer.keyPress(keyCode);
>> }
>>
>> public void keyRelease(KeyCode keyCode) {
>> peer.keyRelease(keyCode);
>> }
>>
>> public final void keyType(KeyCode keyCode) {
>> keyPress(keyCode);
>> keyRelease(keyCode);
>> }
>>
>> ...
>>
>>
>> And so on. The Toolkit class can return a glass robot "peer" which should
>> then only need minor changes  (e.g., to the signatures of methods that have
>> slightly different types) from the current one. The QuantumToolkit
>> implementation of createPeer can construct, initialize, and return the
>> GlassRobot instance. The StubToolkit and DummyToolkit implementations can
>> throw an UnsuppportedOperationException.
>>
>> As for the public API, the set of methods you have seem mostly what we
>> would want. Here are a few quick thoughts:
>>
>> void keyPress(KeyCode keyCode);
>> void keyRelease(KeyCode keyCode);
>> void keyType(KeyCode keyCode);
>>
>> int getMouseX(); // maybe should return double?
>> int getMouseY();
>>
>> Point2D getMousePosition();
>>
>> void mouseMove(int x, int y);   // maybe params should be double?
>>
>> void mouseMove(Point2D location);
>>
>> void mousePress(MouseButton button);// This one seems
>> redundant...covered by the next method
>> void mousePress(MouseButton... buttons);
>>
>> void mouseRelease(MouseButton button);  // This one seems
>> redundant...covered by the next method
>> void mouseRelease(MouseButton... buttons);
>>
>> // I don't see the need for this method
>> void mouseWheel(int wheelAmt, VerticalDirection direction);
>>
>> void mouseWheel(int wheelAmt);
>>
>> Color getPixelColor(int x, int y);  // maybe params should be double?
>>
>> Color getPixelColor(Point2D location);
>>
>> // Probably the following should return WritableImage to match Snapshot.
>> maybe also have a variable that takes a WritableImage to allow caller to
>> allocate and reuse (that might overkill in this case)?
>>
>> Image getScreenCapture(int x, int y, int width, 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

Michael Ennen wrote:

Quick question:

Currently a Robot is created by calling `Application.createRobot` 
which delegates
to the underlying platform-specific application class (GtkApplication, 
WinApplication, etc.)

via `com.sun.glass.ui.Application.GetApplication().createRobot();`


I just meant that the Toolkit class was a convenient place to call 
com.sun.glass.ui.Application.GetApplication().createRobot() -- something 
like this:


Toolkit:

public GlassRobot createRobot() {   // or could be abstract
   throw new UnsupportedOperationException("not implemented");
}

QuantumToolkit:

public GlassRobot createRobot() {
   return com.sun.glass.ui.Application.GetApplication().createRobot();
}

The reason for doing it there is because it already has the mechanism 
for handling QuantumToolkit versus StubToolkit. Otherwise you wouldn't 
need the extra level of indirection.


-- Kevin

You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, 
etc. all extend
the abstract base class GlassRobot (the peer), how will Toolkit be 
able to instantiate
the correct, platform-specific class? Sorry, I got stuck trying to 
implement this part

of your review. The rest is easy for me to follow and will be no problem.


On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth 
> wrote:


Hi Michael,

Here is some quick feedback.

I think what you have is heading in the right direction as far as
the public API goes. I'd like to get some feedback from other
developers as well. I would want to make sure that the API meets
the needs of multiple developers.

I took a look at the public class and as I may have mentioned
earlier, it will help to split the API and the implementation even
further, by creating a peer object as we do for Scene, Stage,
etc., rather than having the glass platform implementation
directly subclass the public Robot class.

Then you can easily delegate to the Glass Robot peer without
having any implementation leak into the public API (e.g., the
overridden create and dispose methods).

So what you would have in that case is something more like this:

public final class Robot {

private final GlassRobot peer;

public Robot() {
// Ensure we have proper permission for creating a robot.
final SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(CREATE_ROBOT_PERMISSION);
}

Application.checkEventThread();

peer = Toolkit.createRobot();
}

// NOTE: for the rest, the peer can do the thread check

public void keyPress(KeyCode keyCode) {
peer.keyPress(keyCode);
}

public void keyRelease(KeyCode keyCode) {
peer.keyRelease(keyCode);
}

public final void keyType(KeyCode keyCode) {
keyPress(keyCode);
keyRelease(keyCode);
}

...


And so on. The Toolkit class can return a glass robot "peer" which
should then only need minor changes  (e.g., to the signatures of
methods that have slightly different types) from the current one.
The QuantumToolkit implementation of createPeer can construct,
initialize, and return the GlassRobot instance. The StubToolkit
and DummyToolkit implementations can throw an
UnsuppportedOperationException.

As for the public API, the set of methods you have seem mostly
what we would want. Here are a few quick thoughts:

void keyPress(KeyCode keyCode);
void keyRelease(KeyCode keyCode);
void keyType(KeyCode keyCode);

int getMouseX(); // maybe should return double?
int getMouseY();

Point2D getMousePosition();

void mouseMove(int x, int y);   // maybe params should be double?

void mouseMove(Point2D location);

void mousePress(MouseButton button);// This one seems
redundant...covered by the next method
void mousePress(MouseButton... buttons);

void mouseRelease(MouseButton button);  // This one seems
redundant...covered by the next method
void mouseRelease(MouseButton... buttons);

// I don't see the need for this method
void mouseWheel(int wheelAmt, VerticalDirection direction);

void mouseWheel(int wheelAmt);

Color getPixelColor(int x, int y);  // maybe params should be double?

Color getPixelColor(Point2D location);

// Probably the following should return WritableImage to match
Snapshot. maybe also have a variable that takes a WritableImage to
allow caller to allocate and reuse (that might overkill in this case)?

Image getScreenCapture(int x, int y, int width, int height); //
maybe params should be double?
Image getScreenCapture(int x, int y, int width, int height,
boolean scaleToFit); // maybe params should be double?
Image getScreenCapture(Rectangle2D 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I should have been more clear in my previous message. I am creating the
Robot thusly:

javafx.scene.robot.Robot constructor (public API so JavaFX users can simply
instantiate one):

public Robot() {
// Ensure we have proper permission for creating a robot.
final SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(CREATE_ROBOT_PERMISSION);
}

peer = GlassRobot.getRobot();
}

static method com.sun.glass.ui.GlassRobot.getRobot():

public static GlassRobot getRobot() {
return Application.GetApplication().createRobot();
}

This seems straight-forward. I am not sure how to change this to Toolkit,
because
the individual application implementations (GtkApplication, WinApplication,
etc.)
all instantiate their correct, platform-specific Robot instance.

On Wed, Mar 21, 2018 at 11:58 PM, Michael Ennen 
wrote:

> Quick question:
>
> Currently a Robot is created by calling `Application.createRobot` which
> delegates
> to the underlying platform-specific application class (GtkApplication,
> WinApplication, etc.)
> via `com.sun.glass.ui.Application.GetApplication().createRobot();`
>
>
> You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, etc.
> all extend
> the abstract base class GlassRobot (the peer), how will Toolkit be able to
> instantiate
> the correct, platform-specific class? Sorry, I got stuck trying to
> implement this part
> of your review. The rest is easy for me to follow and will be no problem.
>
>
> On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Hi Michael,
>>
>> Here is some quick feedback.
>>
>> I think what you have is heading in the right direction as far as the
>> public API goes. I'd like to get some feedback from other developers as
>> well. I would want to make sure that the API meets the needs of multiple
>> developers.
>>
>> I took a look at the public class and as I may have mentioned earlier, it
>> will help to split the API and the implementation even further, by creating
>> a peer object as we do for Scene, Stage, etc., rather than having the glass
>> platform implementation directly subclass the public Robot class.
>>
>> Then you can easily delegate to the Glass Robot peer without having any
>> implementation leak into the public API (e.g., the overridden create and
>> dispose methods).
>>
>> So what you would have in that case is something more like this:
>>
>> public final class Robot {
>>
>> private final GlassRobot peer;
>>
>> public Robot() {
>> // Ensure we have proper permission for creating a robot.
>> final SecurityManager sm = System.getSecurityManager();
>> if (sm != null) {
>> sm.checkPermission(CREATE_ROBOT_PERMISSION);
>> }
>>
>> Application.checkEventThread();
>>
>> peer = Toolkit.createRobot();
>> }
>>
>> // NOTE: for the rest, the peer can do the thread check
>>
>> public void keyPress(KeyCode keyCode) {
>> peer.keyPress(keyCode);
>> }
>>
>> public void keyRelease(KeyCode keyCode) {
>> peer.keyRelease(keyCode);
>> }
>>
>> public final void keyType(KeyCode keyCode) {
>> keyPress(keyCode);
>> keyRelease(keyCode);
>> }
>>
>> ...
>>
>>
>> And so on. The Toolkit class can return a glass robot "peer" which should
>> then only need minor changes  (e.g., to the signatures of methods that have
>> slightly different types) from the current one. The QuantumToolkit
>> implementation of createPeer can construct, initialize, and return the
>> GlassRobot instance. The StubToolkit and DummyToolkit implementations can
>> throw an UnsuppportedOperationException.
>>
>> As for the public API, the set of methods you have seem mostly what we
>> would want. Here are a few quick thoughts:
>>
>> void keyPress(KeyCode keyCode);
>> void keyRelease(KeyCode keyCode);
>> void keyType(KeyCode keyCode);
>>
>> int getMouseX(); // maybe should return double?
>> int getMouseY();
>>
>> Point2D getMousePosition();
>>
>> void mouseMove(int x, int y);   // maybe params should be double?
>>
>> void mouseMove(Point2D location);
>>
>> void mousePress(MouseButton button);// This one seems
>> redundant...covered by the next method
>> void mousePress(MouseButton... buttons);
>>
>> void mouseRelease(MouseButton button);  // This one seems
>> redundant...covered by the next method
>> void mouseRelease(MouseButton... buttons);
>>
>> // I don't see the need for this method
>> void mouseWheel(int wheelAmt, VerticalDirection direction);
>>
>> void mouseWheel(int wheelAmt);
>>
>> Color getPixelColor(int x, int y);  // maybe params should be double?
>>
>> Color getPixelColor(Point2D location);
>>
>> // Probably the following should return WritableImage to match Snapshot.
>> maybe also have a variable that takes a WritableImage to allow caller to
>> allocate and reuse (that might 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Nir Lisker]

Hi Michael,

About the public API, I agree with Kevin that the following methods are
redundant:

- mousePress(MouseButton button)
- mouseRelease(MouseButton button);
- mouseWheel(int wheelAmt, VerticalDirection direction)

About the implementation of getScreenCapture, isn't that conflicting with
the glass.ui.Robot implementation? Do you intend to change that
implementation?

What's the link to the current changeset/webrev?

- Nir

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Quick question:

Currently a Robot is created by calling `Application.createRobot` which
delegates
to the underlying platform-specific application class (GtkApplication,
WinApplication, etc.)
via `com.sun.glass.ui.Application.GetApplication().createRobot();`


You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, etc.
all extend
the abstract base class GlassRobot (the peer), how will Toolkit be able to
instantiate
the correct, platform-specific class? Sorry, I got stuck trying to
implement this part
of your review. The rest is easy for me to follow and will be no problem.


On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth  wrote:

> Hi Michael,
>
> Here is some quick feedback.
>
> I think what you have is heading in the right direction as far as the
> public API goes. I'd like to get some feedback from other developers as
> well. I would want to make sure that the API meets the needs of multiple
> developers.
>
> I took a look at the public class and as I may have mentioned earlier, it
> will help to split the API and the implementation even further, by creating
> a peer object as we do for Scene, Stage, etc., rather than having the glass
> platform implementation directly subclass the public Robot class.
>
> Then you can easily delegate to the Glass Robot peer without having any
> implementation leak into the public API (e.g., the overridden create and
> dispose methods).
>
> So what you would have in that case is something more like this:
>
> public final class Robot {
>
> private final GlassRobot peer;
>
> public Robot() {
> // Ensure we have proper permission for creating a robot.
> final SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(CREATE_ROBOT_PERMISSION);
> }
>
> Application.checkEventThread();
>
> peer = Toolkit.createRobot();
> }
>
> // NOTE: for the rest, the peer can do the thread check
>
> public void keyPress(KeyCode keyCode) {
> peer.keyPress(keyCode);
> }
>
> public void keyRelease(KeyCode keyCode) {
> peer.keyRelease(keyCode);
> }
>
> public final void keyType(KeyCode keyCode) {
> keyPress(keyCode);
> keyRelease(keyCode);
> }
>
> ...
>
>
> And so on. The Toolkit class can return a glass robot "peer" which should
> then only need minor changes  (e.g., to the signatures of methods that have
> slightly different types) from the current one. The QuantumToolkit
> implementation of createPeer can construct, initialize, and return the
> GlassRobot instance. The StubToolkit and DummyToolkit implementations can
> throw an UnsuppportedOperationException.
>
> As for the public API, the set of methods you have seem mostly what we
> would want. Here are a few quick thoughts:
>
> void keyPress(KeyCode keyCode);
> void keyRelease(KeyCode keyCode);
> void keyType(KeyCode keyCode);
>
> int getMouseX(); // maybe should return double?
> int getMouseY();
>
> Point2D getMousePosition();
>
> void mouseMove(int x, int y);   // maybe params should be double?
>
> void mouseMove(Point2D location);
>
> void mousePress(MouseButton button);// This one seems
> redundant...covered by the next method
> void mousePress(MouseButton... buttons);
>
> void mouseRelease(MouseButton button);  // This one seems
> redundant...covered by the next method
> void mouseRelease(MouseButton... buttons);
>
> // I don't see the need for this method
> void mouseWheel(int wheelAmt, VerticalDirection direction);
>
> void mouseWheel(int wheelAmt);
>
> Color getPixelColor(int x, int y);  // maybe params should be double?
>
> Color getPixelColor(Point2D location);
>
> // Probably the following should return WritableImage to match Snapshot.
> maybe also have a variable that takes a WritableImage to allow caller to
> allocate and reuse (that might overkill in this case)?
>
> Image getScreenCapture(int x, int y, int width, int height); // maybe
> params should be double?
> Image getScreenCapture(int x, int y, int width, int height, boolean
> scaleToFit); // maybe params should be double?
> Image getScreenCapture(Rectangle2D region);
> Image getScreenCapture(Rectangle2D region, boolean scaleToFit);
>
> void getScreenCapture(int x, int y, int width, int height, int[] data); //
> Not sure we need / want this one
>
> The biggest question I have is whether we should follow the pattern of the
> other related public APIs in Screen and Stage and use doubles everywhere
> rather than ints. Also, we will need to see whether there are any
> implications for multiple screens (probably not, but the docs will need to
> specify what coordinates the x, and y values are in).
>
> Hopefully this will spark a discussion.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> Ping :)
>
> On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> I'll take a look some time after RDP2 of JDK 10.
>>
>>
>> -- 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Okay, thanks for that review, Kevin.

I will take into account all of the your suggestions (and if any others
come in as well)
and report back soon.

Thanks,
Michael

On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth  wrote:

> Hi Michael,
>
> Here is some quick feedback.
>
> I think what you have is heading in the right direction as far as the
> public API goes. I'd like to get some feedback from other developers as
> well. I would want to make sure that the API meets the needs of multiple
> developers.
>
> I took a look at the public class and as I may have mentioned earlier, it
> will help to split the API and the implementation even further, by creating
> a peer object as we do for Scene, Stage, etc., rather than having the glass
> platform implementation directly subclass the public Robot class.
>
> Then you can easily delegate to the Glass Robot peer without having any
> implementation leak into the public API (e.g., the overridden create and
> dispose methods).
>
> So what you would have in that case is something more like this:
>
> public final class Robot {
>
> private final GlassRobot peer;
>
> public Robot() {
> // Ensure we have proper permission for creating a robot.
> final SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(CREATE_ROBOT_PERMISSION);
> }
>
> Application.checkEventThread();
>
> peer = Toolkit.createRobot();
> }
>
> // NOTE: for the rest, the peer can do the thread check
>
> public void keyPress(KeyCode keyCode) {
> peer.keyPress(keyCode);
> }
>
> public void keyRelease(KeyCode keyCode) {
> peer.keyRelease(keyCode);
> }
>
> public final void keyType(KeyCode keyCode) {
> keyPress(keyCode);
> keyRelease(keyCode);
> }
>
> ...
>
>
> And so on. The Toolkit class can return a glass robot "peer" which should
> then only need minor changes  (e.g., to the signatures of methods that have
> slightly different types) from the current one. The QuantumToolkit
> implementation of createPeer can construct, initialize, and return the
> GlassRobot instance. The StubToolkit and DummyToolkit implementations can
> throw an UnsuppportedOperationException.
>
> As for the public API, the set of methods you have seem mostly what we
> would want. Here are a few quick thoughts:
>
> void keyPress(KeyCode keyCode);
> void keyRelease(KeyCode keyCode);
> void keyType(KeyCode keyCode);
>
> int getMouseX(); // maybe should return double?
> int getMouseY();
>
> Point2D getMousePosition();
>
> void mouseMove(int x, int y);   // maybe params should be double?
>
> void mouseMove(Point2D location);
>
> void mousePress(MouseButton button);// This one seems
> redundant...covered by the next method
> void mousePress(MouseButton... buttons);
>
> void mouseRelease(MouseButton button);  // This one seems
> redundant...covered by the next method
> void mouseRelease(MouseButton... buttons);
>
> // I don't see the need for this method
> void mouseWheel(int wheelAmt, VerticalDirection direction);
>
> void mouseWheel(int wheelAmt);
>
> Color getPixelColor(int x, int y);  // maybe params should be double?
>
> Color getPixelColor(Point2D location);
>
> // Probably the following should return WritableImage to match Snapshot.
> maybe also have a variable that takes a WritableImage to allow caller to
> allocate and reuse (that might overkill in this case)?
>
> Image getScreenCapture(int x, int y, int width, int height); // maybe
> params should be double?
> Image getScreenCapture(int x, int y, int width, int height, boolean
> scaleToFit); // maybe params should be double?
> Image getScreenCapture(Rectangle2D region);
> Image getScreenCapture(Rectangle2D region, boolean scaleToFit);
>
> void getScreenCapture(int x, int y, int width, int height, int[] data); //
> Not sure we need / want this one
>
> The biggest question I have is whether we should follow the pattern of the
> other related public APIs in Screen and Stage and use doubles everywhere
> rather than ints. Also, we will need to see whether there are any
> implications for multiple screens (probably not, but the docs will need to
> specify what coordinates the x, and y values are in).
>
> Hopefully this will spark a discussion.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> Ping :)
>
> On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> I'll take a look some time after RDP2 of JDK 10.
>>
>>
>> -- Kevin
>>
>>
>> Michael Ennen wrote:
>>
>> Hey Kevin,
>>
>> Hope you had a good holiday. Hopefully you will get some time in the
>> coming weeks
>> to review my work.
>>
>> Thanks!
>>
>> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> Sure, no problem. One quick comment is that a common way to solve this
>>> is by delegating to an implementation class, which would then be
>>> 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

Hi Michael,

Here is some quick feedback.

I think what you have is heading in the right direction as far as the 
public API goes. I'd like to get some feedback from other developers as 
well. I would want to make sure that the API meets the needs of multiple 
developers.


I took a look at the public class and as I may have mentioned earlier, 
it will help to split the API and the implementation even further, by 
creating a peer object as we do for Scene, Stage, etc., rather than 
having the glass platform implementation directly subclass the public 
Robot class.


Then you can easily delegate to the Glass Robot peer without having any 
implementation leak into the public API (e.g., the overridden create and 
dispose methods).


So what you would have in that case is something more like this:

public final class Robot {

   private final GlassRobot peer;

   public Robot() {
   // Ensure we have proper permission for creating a robot.
   final SecurityManager sm = System.getSecurityManager();
   if (sm != null) {
   sm.checkPermission(CREATE_ROBOT_PERMISSION);
   }

   Application.checkEventThread();

   peer = Toolkit.createRobot();
   }

   // NOTE: for the rest, the peer can do the thread check

   public void keyPress(KeyCode keyCode) {
   peer.keyPress(keyCode);
   }

   public void keyRelease(KeyCode keyCode) {
   peer.keyRelease(keyCode);
   }

   public final void keyType(KeyCode keyCode) {
   keyPress(keyCode);
   keyRelease(keyCode);
   }

   ...


And so on. The Toolkit class can return a glass robot "peer" which 
should then only need minor changes  (e.g., to the signatures of methods 
that have slightly different types) from the current one. The 
QuantumToolkit implementation of createPeer can construct, initialize, 
and return the GlassRobot instance. The StubToolkit and DummyToolkit 
implementations can throw an UnsuppportedOperationException.


As for the public API, the set of methods you have seem mostly what we 
would want. Here are a few quick thoughts:


void keyPress(KeyCode keyCode);
void keyRelease(KeyCode keyCode);
void keyType(KeyCode keyCode);

int getMouseX(); // maybe should return double?
int getMouseY();

Point2D getMousePosition();

void mouseMove(int x, int y);   // maybe params should be double?

void mouseMove(Point2D location);

void mousePress(MouseButton button);// This one seems 
redundant...covered by the next method

void mousePress(MouseButton... buttons);

void mouseRelease(MouseButton button);  // This one seems 
redundant...covered by the next method

void mouseRelease(MouseButton... buttons);

// I don't see the need for this method
void mouseWheel(int wheelAmt, VerticalDirection direction);

void mouseWheel(int wheelAmt);

Color getPixelColor(int x, int y);  // maybe params should be double?

Color getPixelColor(Point2D location);

// Probably the following should return WritableImage to match Snapshot. 
maybe also have a variable that takes a WritableImage to allow caller to 
allocate and reuse (that might overkill in this case)?


Image getScreenCapture(int x, int y, int width, int height); // maybe 
params should be double?
Image getScreenCapture(int x, int y, int width, int height, boolean 
scaleToFit); // maybe params should be double?

Image getScreenCapture(Rectangle2D region);
Image getScreenCapture(Rectangle2D region, boolean scaleToFit);

void getScreenCapture(int x, int y, int width, int height, int[] data); 
// Not sure we need / want this one


The biggest question I have is whether we should follow the pattern of 
the other related public APIs in Screen and Stage and use doubles 
everywhere rather than ints. Also, we will need to see whether there are 
any implications for multiple screens (probably not, but the docs will 
need to specify what coordinates the x, and y values are in).


Hopefully this will spark a discussion.

-- Kevin


Michael Ennen wrote:

Ping :)

On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth 
> wrote:


I'll take a look some time after RDP2 of JDK 10.


-- Kevin


Michael Ennen wrote:

Hey Kevin,

Hope you had a good holiday. Hopefully you will get some time in
the coming weeks
to review my work.

Thanks!

On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth
>
wrote:

Sure, no problem. One quick comment is that a common way to
solve this is by delegating to an implementation class, which
would then be sub-classes.


-- Kevin


Michael Ennen wrote:

I am not trying to be a burden here. I understand that you
may not have time to hand-hold
to this degree. I will try and make progress, sorry for the
follow up question.

On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

I will do an initial review of the API today and suggest next steps.

-- Kevin


Michael Ennen wrote:

Ping :)

On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth 
> wrote:


I'll take a look some time after RDP2 of JDK 10.


-- Kevin


Michael Ennen wrote:

Hey Kevin,

Hope you had a good holiday. Hopefully you will get some time in
the coming weeks
to review my work.

Thanks!

On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth
>
wrote:

Sure, no problem. One quick comment is that a common way to
solve this is by delegating to an implementation class, which
would then be sub-classes.


-- Kevin


Michael Ennen wrote:

I am not trying to be a burden here. I understand that you
may not have time to hand-hold
to this degree. I will try and make progress, sorry for the
follow up question.

On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen
> wrote:

How can Robot call into the implementation when it is a
super class of the implementations?

On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth
> wrote:



Michael Ennen wrote:

I have a question about how to proceed with the
Robot code.

The base abstract Robot class
is: 
https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java



As you can see for each method, such as
"getMouseX()" there is a "_" prefixed method
which is abstract and a non-prefixed method:

protected abstract int _getMouseX();

public int getMouseX() {
Application.checkEventThread();
return _getMouseX();
}

I have copied this from the private Robot API.

Is there a better way to do this? Would this pass
review?


Yes there are better ways to do this. No it would
not pass review, since this would be leaking
implementation into the public API.

Rather than copying the public / protected methods
from the internal package, it probably makes more
sense to start with what a Robot API should look
like and then have that call into the implementation
(suitably modified so it better matches the public
API). For one thing you will then leave the
implementation, including the per-platform code,
where it belongs -- in glass. The Robot API can be
informed by the current implementation, but should
not be defined by it.

-- Kevin




Thanks very much.


On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth
> wrote:

Glad you got the build working. You can post
back on this thread when you are ready.


-- Kevin


Michael Ennen wrote:

Correction:

Adding ""--add-exports
javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
to buildSrc/addExports.

For posterity :)

On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen
> wrote:

Ah, indeed, missed adding "--add-opens
javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
to buildSrc/addExports.
Thanks for the guidance on that.

I will continue to work on this in the
GitHub repo and polish it up (add
javadocs, better method signatures, etc.)
and 
even plan on maybe improving the

underlying native Robot implementations
(for example fixing/improving the
way color profiles are handled for MacRobot).

I will also take a look at "fixing"
JemmyFX to use the new public API (as well
as any other place in the JavaFX code
base that 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Ping :)

On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth 
wrote:

> I'll take a look some time after RDP2 of JDK 10.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> Hey Kevin,
>
> Hope you had a good holiday. Hopefully you will get some time in the
> coming weeks
> to review my work.
>
> Thanks!
>
> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Sure, no problem. One quick comment is that a common way to solve this is
>> by delegating to an implementation class, which would then be sub-classes.
>>
>>
>> -- Kevin
>>
>>
>> Michael Ennen wrote:
>>
>> I am not trying to be a burden here. I understand that you may not have
>> time to hand-hold
>> to this degree. I will try and make progress, sorry for the follow up
>> question.
>>
>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen 
>> wrote:
>>
>>> How can Robot call into the implementation when it is a super class of
>>> the implementations?
>>>
>>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>


 Michael Ennen wrote:

 I have a question about how to proceed with the Robot code.

 The base abstract Robot class is: https://github.com/brcolow
 /openjfx/blob/master/modules/javafx.graphics/src/main/java/j
 avafx/scene/robot/Robot.java

 As you can see for each method, such as "getMouseX()" there is a "_"
 prefixed method
 which is abstract and a non-prefixed method:

 protected abstract int _getMouseX();

 public int getMouseX() {
 Application.checkEventThread();
 return _getMouseX();
 }

 I have copied this from the private Robot API.

 Is there a better way to do this? Would this pass review?


 Yes there are better ways to do this. No it would not pass review,
 since this would be leaking implementation into the public API.

 Rather than copying the public / protected methods from the internal
 package, it probably makes more sense to start with what a Robot API should
 look like and then have that call into the implementation (suitably
 modified so it better matches the public API). For one thing you will then
 leave the implementation, including the per-platform code, where it belongs
 -- in glass. The Robot API can be informed by the current implementation,
 but should not be defined by it.

 -- Kevin



 Thanks very much.


 On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth <
 kevin.rushfo...@oracle.com> wrote:

> Glad you got the build working. You can post back on this thread when
> you are ready.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> Correction:
>
> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
> to buildSrc/addExports.
>
> For posterity :)
>
> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen 
> wrote:
>
>> Ah, indeed, missed adding "--add-opens 
>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
>> to buildSrc/addExports.
>> Thanks for the guidance on that.
>>
>> I will continue to work on this in the GitHub repo and polish it up
>> (add javadocs, better method signatures, etc.) and
>> even plan on maybe improving the underlying native Robot
>> implementations (for example fixing/improving the
>> way color profiles are handled for MacRobot).
>>
>> I will also take a look at "fixing" JemmyFX to use the new public API
>> (as well as any other place in the JavaFX code
>> base that does).
>>
>> I was expecting that JDK 11 would be the appropriate time frame,
>> especially because it will be the release where
>> private APIs will be totally inaccessible, correct?
>>
>> After I get it in a reasonable state should I post back on this
>> mailing list thread or what would be the appropriate
>> way?
>>
>> Thanks Kevin.
>>
>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> This is a limitation of the the way --patch-modules works. You will
>>> need to add an entry in:
>>>
>>> buildSrc/addExports
>>>
>>> Btw, as for the proposal itself, this might need to be a JEP
>>> depending on the scope. In any case, it could be considered in the JDK 
>>> 11
>>> time frame, but there are several things that need to be worked out 
>>> before
>>> making Robot a public API, including the fact that the JemmyFX 
>>> framework in
>>> the openjfx/jfx/tests directory uses Robot. Once you get a working
>>> prototype, it would be interesting to discuss it in more detail.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Michael Ennen wrote:
>>>
>>> Currently I am stuck with tests not being able to see the 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Sounds great. Much appreciated.

On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth 
wrote:

> I'll take a look some time after RDP2 of JDK 10.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> Hey Kevin,
>
> Hope you had a good holiday. Hopefully you will get some time in the
> coming weeks
> to review my work.
>
> Thanks!
>
> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Sure, no problem. One quick comment is that a common way to solve this is
>> by delegating to an implementation class, which would then be sub-classes.
>>
>>
>> -- Kevin
>>
>>
>> Michael Ennen wrote:
>>
>> I am not trying to be a burden here. I understand that you may not have
>> time to hand-hold
>> to this degree. I will try and make progress, sorry for the follow up
>> question.
>>
>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen 
>> wrote:
>>
>>> How can Robot call into the implementation when it is a super class of
>>> the implementations?
>>>
>>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>


 Michael Ennen wrote:

 I have a question about how to proceed with the Robot code.

 The base abstract Robot class is: https://github.com/brcolow
 /openjfx/blob/master/modules/javafx.graphics/src/main/java/j
 avafx/scene/robot/Robot.java

 As you can see for each method, such as "getMouseX()" there is a "_"
 prefixed method
 which is abstract and a non-prefixed method:

 protected abstract int _getMouseX();

 public int getMouseX() {
 Application.checkEventThread();
 return _getMouseX();
 }

 I have copied this from the private Robot API.

 Is there a better way to do this? Would this pass review?


 Yes there are better ways to do this. No it would not pass review,
 since this would be leaking implementation into the public API.

 Rather than copying the public / protected methods from the internal
 package, it probably makes more sense to start with what a Robot API should
 look like and then have that call into the implementation (suitably
 modified so it better matches the public API). For one thing you will then
 leave the implementation, including the per-platform code, where it belongs
 -- in glass. The Robot API can be informed by the current implementation,
 but should not be defined by it.

 -- Kevin



 Thanks very much.


 On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth <
 kevin.rushfo...@oracle.com> wrote:

> Glad you got the build working. You can post back on this thread when
> you are ready.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> Correction:
>
> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
> to buildSrc/addExports.
>
> For posterity :)
>
> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen 
> wrote:
>
>> Ah, indeed, missed adding "--add-opens 
>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
>> to buildSrc/addExports.
>> Thanks for the guidance on that.
>>
>> I will continue to work on this in the GitHub repo and polish it up
>> (add javadocs, better method signatures, etc.) and
>> even plan on maybe improving the underlying native Robot
>> implementations (for example fixing/improving the
>> way color profiles are handled for MacRobot).
>>
>> I will also take a look at "fixing" JemmyFX to use the new public API
>> (as well as any other place in the JavaFX code
>> base that does).
>>
>> I was expecting that JDK 11 would be the appropriate time frame,
>> especially because it will be the release where
>> private APIs will be totally inaccessible, correct?
>>
>> After I get it in a reasonable state should I post back on this
>> mailing list thread or what would be the appropriate
>> way?
>>
>> Thanks Kevin.
>>
>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> This is a limitation of the the way --patch-modules works. You will
>>> need to add an entry in:
>>>
>>> buildSrc/addExports
>>>
>>> Btw, as for the proposal itself, this might need to be a JEP
>>> depending on the scope. In any case, it could be considered in the JDK 
>>> 11
>>> time frame, but there are several things that need to be worked out 
>>> before
>>> making Robot a public API, including the fact that the JemmyFX 
>>> framework in
>>> the openjfx/jfx/tests directory uses Robot. Once you get a working
>>> prototype, it would be interesting to discuss it in more detail.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Michael Ennen wrote:
>>>
>>> Currently I am stuck with tests not 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

I'll take a look some time after RDP2 of JDK 10.

-- Kevin


Michael Ennen wrote:

Hey Kevin,

Hope you had a good holiday. Hopefully you will get some time in the 
coming weeks

to review my work.

Thanks!

On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth 
> wrote:


Sure, no problem. One quick comment is that a common way to solve
this is by delegating to an implementation class, which would then
be sub-classes.


-- Kevin


Michael Ennen wrote:

I am not trying to be a burden here. I understand that you may
not have time to hand-hold
to this degree. I will try and make progress, sorry for the
follow up question.

On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen
> wrote:

How can Robot call into the implementation when it is a super
class of the implementations?

On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth
> wrote:



Michael Ennen wrote:

I have a question about how to proceed with the Robot code.

The base abstract Robot class
is: 
https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java



As you can see for each method, such as "getMouseX()"
there is a "_" prefixed method
which is abstract and a non-prefixed method:

protected abstract int _getMouseX();

public int getMouseX() {
Application.checkEventThread();
return _getMouseX();
}

I have copied this from the private Robot API.

Is there a better way to do this? Would this pass review?


Yes there are better ways to do this. No it would not
pass review, since this would be leaking implementation
into the public API.

Rather than copying the public / protected methods from
the internal package, it probably makes more sense to
start with what a Robot API should look like and then
have that call into the implementation (suitably modified
so it better matches the public API). For one thing you
will then leave the implementation, including the
per-platform code, where it belongs -- in glass. The
Robot API can be informed by the current implementation,
but should not be defined by it.

-- Kevin




Thanks very much.


On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth
> wrote:

Glad you got the build working. You can post back on
this thread when you are ready.


-- Kevin


Michael Ennen wrote:

Correction:

Adding ""--add-exports
javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to
buildSrc/addExports.

For posterity :)

On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen
> wrote:

Ah, indeed, missed adding "--add-opens
javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
to buildSrc/addExports.
Thanks for the guidance on that.

I will continue to work on this in the GitHub
repo and polish it up (add javadocs, better
method signatures, etc.) and 
even plan on maybe improving the underlying

native Robot implementations (for example
fixing/improving the
way color profiles are handled for MacRobot).

I will also take a look at "fixing" JemmyFX to
use the new public API (as well as any other
place in the JavaFX code
base that does).

I was expecting that JDK 11 would be the
appropriate time frame, especially because it
will be the release where
private APIs will be totally inaccessible, correct?

After I get it in a reasonable state should I
post back on this mailing list thread or what
would be the appropriate
way?

Thanks Kevin.

On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Hey Kevin,

Hope you had a good holiday. Hopefully you will get some time in the coming
weeks
to review my work.

Thanks!

On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth  wrote:

> Sure, no problem. One quick comment is that a common way to solve this is
> by delegating to an implementation class, which would then be sub-classes.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> I am not trying to be a burden here. I understand that you may not have
> time to hand-hold
> to this degree. I will try and make progress, sorry for the follow up
> question.
>
> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen 
> wrote:
>
>> How can Robot call into the implementation when it is a super class of
>> the implementations?
>>
>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>>
>>>
>>> Michael Ennen wrote:
>>>
>>> I have a question about how to proceed with the Robot code.
>>>
>>> The base abstract Robot class is: https://github.com/brcolow
>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j
>>> avafx/scene/robot/Robot.java
>>>
>>> As you can see for each method, such as "getMouseX()" there is a "_"
>>> prefixed method
>>> which is abstract and a non-prefixed method:
>>>
>>> protected abstract int _getMouseX();
>>>
>>> public int getMouseX() {
>>> Application.checkEventThread();
>>> return _getMouseX();
>>> }
>>>
>>> I have copied this from the private Robot API.
>>>
>>> Is there a better way to do this? Would this pass review?
>>>
>>>
>>> Yes there are better ways to do this. No it would not pass review, since
>>> this would be leaking implementation into the public API.
>>>
>>> Rather than copying the public / protected methods from the internal
>>> package, it probably makes more sense to start with what a Robot API should
>>> look like and then have that call into the implementation (suitably
>>> modified so it better matches the public API). For one thing you will then
>>> leave the implementation, including the per-platform code, where it belongs
>>> -- in glass. The Robot API can be informed by the current implementation,
>>> but should not be defined by it.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Thanks very much.
>>>
>>>
>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>
 Glad you got the build working. You can post back on this thread when
 you are ready.


 -- Kevin


 Michael Ennen wrote:

 Correction:

 Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
 to buildSrc/addExports.

 For posterity :)

 On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen 
 wrote:

> Ah, indeed, missed adding "--add-opens 
> javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
> to buildSrc/addExports.
> Thanks for the guidance on that.
>
> I will continue to work on this in the GitHub repo and polish it up
> (add javadocs, better method signatures, etc.) and
> even plan on maybe improving the underlying native Robot
> implementations (for example fixing/improving the
> way color profiles are handled for MacRobot).
>
> I will also take a look at "fixing" JemmyFX to use the new public API
> (as well as any other place in the JavaFX code
> base that does).
>
> I was expecting that JDK 11 would be the appropriate time frame,
> especially because it will be the release where
> private APIs will be totally inaccessible, correct?
>
> After I get it in a reasonable state should I post back on this
> mailing list thread or what would be the appropriate
> way?
>
> Thanks Kevin.
>
> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> This is a limitation of the the way --patch-modules works. You will
>> need to add an entry in:
>>
>> buildSrc/addExports
>>
>> Btw, as for the proposal itself, this might need to be a JEP
>> depending on the scope. In any case, it could be considered in the JDK 11
>> time frame, but there are several things that need to be worked out 
>> before
>> making Robot a public API, including the fact that the JemmyFX framework 
>> in
>> the openjfx/jfx/tests directory uses Robot. Once you get a working
>> prototype, it would be interesting to discuss it in more detail.
>>
>> -- Kevin
>>
>>
>>
>> Michael Ennen wrote:
>>
>> Currently I am stuck with tests not being able to see the new
>> "javafx.scene.robot" module:
>>
>>
>>
>> Task :systemTests:compileTestJava
>>
>>
>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
>> error: package javafx.scene.robot is not visible
>> import javafx.scene.robot.Robot;
>>  

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I have created an orphan branch with the Robot API webrev:

https://github.com/brcolow/openjfx/tree/robot-webrev

You can clone/"download" it via:

git clone https://github.com/brcolow/openjfx --branch robot-webrev
--single-branch ~/robot-webrev

This will use git to essentially download the webrev, without all the
rest of the repository to ~/robot-webrev (or wherever you would like it to
clone).

Sorry I currently don't have an HTTP server for hosting the webrev.

Thanks,
Michael Ennen

On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth  wrote:

> Sure, no problem. One quick comment is that a common way to solve this is
> by delegating to an implementation class, which would then be sub-classes.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> I am not trying to be a burden here. I understand that you may not have
> time to hand-hold
> to this degree. I will try and make progress, sorry for the follow up
> question.
>
> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen 
> wrote:
>
>> How can Robot call into the implementation when it is a super class of
>> the implementations?
>>
>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>>
>>>
>>> Michael Ennen wrote:
>>>
>>> I have a question about how to proceed with the Robot code.
>>>
>>> The base abstract Robot class is: https://github.com/brcolow
>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j
>>> avafx/scene/robot/Robot.java
>>>
>>> As you can see for each method, such as "getMouseX()" there is a "_"
>>> prefixed method
>>> which is abstract and a non-prefixed method:
>>>
>>> protected abstract int _getMouseX();
>>>
>>> public int getMouseX() {
>>> Application.checkEventThread();
>>> return _getMouseX();
>>> }
>>>
>>> I have copied this from the private Robot API.
>>>
>>> Is there a better way to do this? Would this pass review?
>>>
>>>
>>> Yes there are better ways to do this. No it would not pass review, since
>>> this would be leaking implementation into the public API.
>>>
>>> Rather than copying the public / protected methods from the internal
>>> package, it probably makes more sense to start with what a Robot API should
>>> look like and then have that call into the implementation (suitably
>>> modified so it better matches the public API). For one thing you will then
>>> leave the implementation, including the per-platform code, where it belongs
>>> -- in glass. The Robot API can be informed by the current implementation,
>>> but should not be defined by it.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Thanks very much.
>>>
>>>
>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>
 Glad you got the build working. You can post back on this thread when
 you are ready.


 -- Kevin


 Michael Ennen wrote:

 Correction:

 Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
 to buildSrc/addExports.

 For posterity :)

 On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen 
 wrote:

> Ah, indeed, missed adding "--add-opens 
> javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
> to buildSrc/addExports.
> Thanks for the guidance on that.
>
> I will continue to work on this in the GitHub repo and polish it up
> (add javadocs, better method signatures, etc.) and
> even plan on maybe improving the underlying native Robot
> implementations (for example fixing/improving the
> way color profiles are handled for MacRobot).
>
> I will also take a look at "fixing" JemmyFX to use the new public API
> (as well as any other place in the JavaFX code
> base that does).
>
> I was expecting that JDK 11 would be the appropriate time frame,
> especially because it will be the release where
> private APIs will be totally inaccessible, correct?
>
> After I get it in a reasonable state should I post back on this
> mailing list thread or what would be the appropriate
> way?
>
> Thanks Kevin.
>
> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> This is a limitation of the the way --patch-modules works. You will
>> need to add an entry in:
>>
>> buildSrc/addExports
>>
>> Btw, as for the proposal itself, this might need to be a JEP
>> depending on the scope. In any case, it could be considered in the JDK 11
>> time frame, but there are several things that need to be worked out 
>> before
>> making Robot a public API, including the fact that the JemmyFX framework 
>> in
>> the openjfx/jfx/tests directory uses Robot. Once you get a working
>> prototype, it would be interesting to discuss it in more detail.
>>
>> -- Kevin
>>
>>
>>
>> Michael Ennen wrote:
>>
>> Currently I am stuck with tests not being 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Just a quick note for clarification:

I was able to make the small changes I mentioned (removing the
color profile experiments and incorrect log statement) to GlassRobot.m
without affecting the commit hashes so the URLs should still work,
but will reflect the newest changes from my end.

Sorry for all the extra noise, just want to be clear.

(P.S. Kevin: Do you prefer I use Reply-To-All or only reply to openjfx-dev?
I am not sure what is the modus operandi for this list).

Thanks,
Michael Ennen

On Tue, Dec 26, 2017 at 10:08 PM, Michael Ennen 
wrote:

> I forgot to mention one thing:
>
> There is quite a large amount of changes to GlassRobot.m for macOS.
> This was purely experimental and was copied almost wholesale
> from Chromium (or was it Firefox?). I wanted to see if messing around
> with setting the color profile of the display allowed for exact color
> matching
> via the robot on macOS. Setting the color profile is not part of the Robot
> proposal and will be removed (mostly because of license issues but also
> because it's really outside the scope).
>
> Specifically I am talking about the following static methods added to:
> "modules/javafx.graphics/src/main/native-glass/mac/GlassRobot.m":
>
> Starting with: "originalColorProfileURLs" and ending with
> "restoreUserColorProfile".
>
> I also noticed that I messed up the logging statements in some of the
> native Robots but will hold off changing them because it will mess up
> the commit hash I posted in the previous message. Once I get feedback
> I will incorporate make this minor fixups in addition to responding/fixing
> the feedback.
>
> Regards,
> Michael Ennen
>
>
> On Tue, Dec 26, 2017 at 9:35 PM, Michael Ennen 
> wrote:
>
>> I have completed what I would call a first draft of moving the Robot to
>> JavaFX
>> public API.
>>
>> This commit: https://github.com/brcolow/openjfx/commit/321f949575
>> a201fe28a2ff79c9590daf8db375a8
>>
>> Includes all the relevant changes necessary to move the glass robot into
>> the public
>> API.
>>
>> I have some other commits on that repository, but they are unrelated and
>> not
>> part of the Robot proposal at all.
>>
>> Except for the most recent commit:
>>
>> https://github.com/brcolow/openjfx/commit/e3250c95d36a467efd
>> 6002dc213cf27668b3f6e0
>>
>> which explores adding support for the back/forward mouse buttons
>> (JDK-8090930),
>> also known as mouse buttons 4 and 5 to JavaFX. This is essentially
>> independent from
>> the Robot proposal except if there is interested in this and it (or
>> something like it,
>> or based on it), is merged then I can easily adapt the native robot
>> implementations
>> (GtkRobot, MonocleRobot, MacRobot, IOsRobot, and WinRobot) to support
>> these additional mouse keys.
>>
>> Happy holidays all,
>> Michael Ennen
>>
>> On Sat, Dec 23, 2017 at 6:00 PM, Michael Ennen 
>> wrote:
>>
>>> Kevin,
>>>
>>> You mentioned in your initial response that Jemmy would need to updated
>>> with any changes
>>> that result from moving Robot into the JavaFX public API. However, from
>>> what I can tell
>>> from a cursory glance, Jemmy seems to use "java.awt.Robot" and not the
>>> JavaFX Glass
>>> Robot API and thus no changes to Jemmy would be required after moving
>>> Robot to the
>>> JavaFX public API.
>>>
>>> Am I missing something?
>>>
>>> Thanks, happy holidays (not expecting a response for a while :) ).
>>>
>>>
>>>
>>> On Fri, Dec 22, 2017 at 10:51 PM, Michael Ennen 
>>> wrote:
>>>
 I didn't realize "_1" is an escape character in JNI method naming and
 is only
 needed when the method has a "_" in its' name. Nevermind!

 On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen 
 wrote:

> I have made quite a bit of good progress I think:
>
> https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc0
> 7b21bdcb575528d8a58eaf
>
> The public API is starting to look much cleaner:
>
> https://github.com/brcolow/openjfx/blob/master/modules/javaf
> x.graphics/src/main/java/javafx/scene/robot/Robot.java
>
> Still a lot to do.
>
> Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot
> but I am unsure why:
>
>   java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot.
> getScreenCapture([I)V
> at javafx.graphics/com.sun.glass.
> ui.gtk.GtkRobot.getScreenCapture(Native Method)
> at javafx.graphics/com.sun.glass.
> ui.gtk.GtkRobot.getPixelColor(GtkRobot.java:93)
>
> I have the following Java method in GtkRobot.java:
>
> @Override native protected void getScreenCapture(int x, int y, int
> width, int height, int[] data);
>
> Which is overriding the abstract method in Robot.java:
>
> protected abstract void getScreenCapture(int x, int y, int width, int
> height, int[] data);
>
> and it is implemented in 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I forgot to mention one thing:

There is quite a large amount of changes to GlassRobot.m for macOS.
This was purely experimental and was copied almost wholesale
from Chromium (or was it Firefox?). I wanted to see if messing around
with setting the color profile of the display allowed for exact color
matching
via the robot on macOS. Setting the color profile is not part of the Robot
proposal and will be removed (mostly because of license issues but also
because it's really outside the scope).

Specifically I am talking about the following static methods added to:
"modules/javafx.graphics/src/main/native-glass/mac/GlassRobot.m":

Starting with: "originalColorProfileURLs" and ending with
"restoreUserColorProfile".

I also noticed that I messed up the logging statements in some of the
native Robots but will hold off changing them because it will mess up
the commit hash I posted in the previous message. Once I get feedback
I will incorporate make this minor fixups in addition to responding/fixing
the feedback.

Regards,
Michael Ennen


On Tue, Dec 26, 2017 at 9:35 PM, Michael Ennen  wrote:

> I have completed what I would call a first draft of moving the Robot to
> JavaFX
> public API.
>
> This commit: https://github.com/brcolow/openjfx/commit/
> 321f949575a201fe28a2ff79c9590daf8db375a8
>
> Includes all the relevant changes necessary to move the glass robot into
> the public
> API.
>
> I have some other commits on that repository, but they are unrelated and
> not
> part of the Robot proposal at all.
>
> Except for the most recent commit:
>
> https://github.com/brcolow/openjfx/commit/e3250c95d36a467efd6002dc213cf2
> 7668b3f6e0
>
> which explores adding support for the back/forward mouse buttons
> (JDK-8090930),
> also known as mouse buttons 4 and 5 to JavaFX. This is essentially
> independent from
> the Robot proposal except if there is interested in this and it (or
> something like it,
> or based on it), is merged then I can easily adapt the native robot
> implementations
> (GtkRobot, MonocleRobot, MacRobot, IOsRobot, and WinRobot) to support
> these additional mouse keys.
>
> Happy holidays all,
> Michael Ennen
>
> On Sat, Dec 23, 2017 at 6:00 PM, Michael Ennen 
> wrote:
>
>> Kevin,
>>
>> You mentioned in your initial response that Jemmy would need to updated
>> with any changes
>> that result from moving Robot into the JavaFX public API. However, from
>> what I can tell
>> from a cursory glance, Jemmy seems to use "java.awt.Robot" and not the
>> JavaFX Glass
>> Robot API and thus no changes to Jemmy would be required after moving
>> Robot to the
>> JavaFX public API.
>>
>> Am I missing something?
>>
>> Thanks, happy holidays (not expecting a response for a while :) ).
>>
>>
>>
>> On Fri, Dec 22, 2017 at 10:51 PM, Michael Ennen 
>> wrote:
>>
>>> I didn't realize "_1" is an escape character in JNI method naming and is
>>> only
>>> needed when the method has a "_" in its' name. Nevermind!
>>>
>>> On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen 
>>> wrote:
>>>
 I have made quite a bit of good progress I think:

 https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc0
 7b21bdcb575528d8a58eaf

 The public API is starting to look much cleaner:

 https://github.com/brcolow/openjfx/blob/master/modules/javaf
 x.graphics/src/main/java/javafx/scene/robot/Robot.java

 Still a lot to do.

 Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but
 I am unsure why:

   java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot.
 getScreenCapture([I)V
 at 
 javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native
 Method)
 at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor(
 GtkRobot.java:93)

 I have the following Java method in GtkRobot.java:

 @Override native protected void getScreenCapture(int x, int y, int
 width, int height, int[] data);

 Which is overriding the abstract method in Robot.java:

 protected abstract void getScreenCapture(int x, int y, int width, int
 height, int[] data);

 and it is implemented in GlassRobot.cpp thusly:

 /*
  * Class: com_sun_glass_ui_gtk_GtkRobot
  * Method:getScreenCapture
  * Signature: ([I)V
  */
 JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_GtkR
 obot_1getScreenCapture
   (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height,
 jintArray data)
 {
 (void)obj;

 GdkPixbuf *screenshot, *tmp;
 GdkWindow *root_window = gdk_get_default_root_window();

 tmp = glass_pixbuf_from_window(root_window, x, y, width, height);
 screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0);
 g_object_unref(tmp);

 jint *pixels = (jint *)convert_BGRA_to_RGBA((int*)g
 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I have completed what I would call a first draft of moving the Robot to
JavaFX
public API.

This commit:
https://github.com/brcolow/openjfx/commit/321f949575a201fe28a2ff79c9590daf8db375a8

Includes all the relevant changes necessary to move the glass robot into
the public
API.

I have some other commits on that repository, but they are unrelated and not
part of the Robot proposal at all.

Except for the most recent commit:

https://github.com/brcolow/openjfx/commit/e3250c95d36a467efd6002dc213cf27668b3f6e0

which explores adding support for the back/forward mouse buttons
(JDK-8090930),
also known as mouse buttons 4 and 5 to JavaFX. This is essentially
independent from
the Robot proposal except if there is interested in this and it (or
something like it,
or based on it), is merged then I can easily adapt the native robot
implementations
(GtkRobot, MonocleRobot, MacRobot, IOsRobot, and WinRobot) to support
these additional mouse keys.

Happy holidays all,
Michael Ennen

On Sat, Dec 23, 2017 at 6:00 PM, Michael Ennen  wrote:

> Kevin,
>
> You mentioned in your initial response that Jemmy would need to updated
> with any changes
> that result from moving Robot into the JavaFX public API. However, from
> what I can tell
> from a cursory glance, Jemmy seems to use "java.awt.Robot" and not the
> JavaFX Glass
> Robot API and thus no changes to Jemmy would be required after moving
> Robot to the
> JavaFX public API.
>
> Am I missing something?
>
> Thanks, happy holidays (not expecting a response for a while :) ).
>
>
>
> On Fri, Dec 22, 2017 at 10:51 PM, Michael Ennen 
> wrote:
>
>> I didn't realize "_1" is an escape character in JNI method naming and is
>> only
>> needed when the method has a "_" in its' name. Nevermind!
>>
>> On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen 
>> wrote:
>>
>>> I have made quite a bit of good progress I think:
>>>
>>> https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc0
>>> 7b21bdcb575528d8a58eaf
>>>
>>> The public API is starting to look much cleaner:
>>>
>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf
>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java
>>>
>>> Still a lot to do.
>>>
>>> Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but
>>> I am unsure why:
>>>
>>>   java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot.
>>> getScreenCapture([I)V
>>> at 
>>> javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native
>>> Method)
>>> at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor(
>>> GtkRobot.java:93)
>>>
>>> I have the following Java method in GtkRobot.java:
>>>
>>> @Override native protected void getScreenCapture(int x, int y, int
>>> width, int height, int[] data);
>>>
>>> Which is overriding the abstract method in Robot.java:
>>>
>>> protected abstract void getScreenCapture(int x, int y, int width, int
>>> height, int[] data);
>>>
>>> and it is implemented in GlassRobot.cpp thusly:
>>>
>>> /*
>>>  * Class: com_sun_glass_ui_gtk_GtkRobot
>>>  * Method:getScreenCapture
>>>  * Signature: ([I)V
>>>  */
>>> JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_GtkR
>>> obot_1getScreenCapture
>>>   (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height,
>>> jintArray data)
>>> {
>>> (void)obj;
>>>
>>> GdkPixbuf *screenshot, *tmp;
>>> GdkWindow *root_window = gdk_get_default_root_window();
>>>
>>> tmp = glass_pixbuf_from_window(root_window, x, y, width, height);
>>> screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0);
>>> g_object_unref(tmp);
>>>
>>> jint *pixels = (jint *)convert_BGRA_to_RGBA((int*)g
>>> dk_pixbuf_get_pixels(screenshot), width * 4, height);
>>> env->SetIntArrayRegion(data, 0, height * width, pixels);
>>> g_free(pixels);
>>>
>>> g_object_unref(screenshot);
>>> }
>>>
>>> Have I somehow messed up the signature? As you can see I removed one of
>>> the "_" prefixes
>>> to "1getScreenCapture" (which seemed to work for the other Robots) as
>>> necessary because
>>> the native method is no longer itself prefixed with "_".
>>>
>>> Thanks again.
>>>
>>> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>
 Sure, no problem. One quick comment is that a common way to solve this
 is by delegating to an implementation class, which would then be
 sub-classes.


 -- Kevin


 Michael Ennen wrote:

 I am not trying to be a burden here. I understand that you may not have
 time to hand-hold
 to this degree. I will try and make progress, sorry for the follow up
 question.

 On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen 
 wrote:

> How can Robot call into the implementation when it is a super class of
> the implementations?
>
> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth <
> 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Kevin,

You mentioned in your initial response that Jemmy would need to updated
with any changes
that result from moving Robot into the JavaFX public API. However, from
what I can tell
from a cursory glance, Jemmy seems to use "java.awt.Robot" and not the
JavaFX Glass
Robot API and thus no changes to Jemmy would be required after moving Robot
to the
JavaFX public API.

Am I missing something?

Thanks, happy holidays (not expecting a response for a while :) ).



On Fri, Dec 22, 2017 at 10:51 PM, Michael Ennen 
wrote:

> I didn't realize "_1" is an escape character in JNI method naming and is
> only
> needed when the method has a "_" in its' name. Nevermind!
>
> On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen 
> wrote:
>
>> I have made quite a bit of good progress I think:
>>
>> https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc0
>> 7b21bdcb575528d8a58eaf
>>
>> The public API is starting to look much cleaner:
>>
>> https://github.com/brcolow/openjfx/blob/master/modules/javaf
>> x.graphics/src/main/java/javafx/scene/robot/Robot.java
>>
>> Still a lot to do.
>>
>> Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but I
>> am unsure why:
>>
>>   java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot.
>> getScreenCapture([I)V
>> at 
>> javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native
>> Method)
>> at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor(
>> GtkRobot.java:93)
>>
>> I have the following Java method in GtkRobot.java:
>>
>> @Override native protected void getScreenCapture(int x, int y, int width,
>> int height, int[] data);
>>
>> Which is overriding the abstract method in Robot.java:
>>
>> protected abstract void getScreenCapture(int x, int y, int width, int
>> height, int[] data);
>>
>> and it is implemented in GlassRobot.cpp thusly:
>>
>> /*
>>  * Class: com_sun_glass_ui_gtk_GtkRobot
>>  * Method:getScreenCapture
>>  * Signature: ([I)V
>>  */
>> JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_GtkR
>> obot_1getScreenCapture
>>   (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height,
>> jintArray data)
>> {
>> (void)obj;
>>
>> GdkPixbuf *screenshot, *tmp;
>> GdkWindow *root_window = gdk_get_default_root_window();
>>
>> tmp = glass_pixbuf_from_window(root_window, x, y, width, height);
>> screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0);
>> g_object_unref(tmp);
>>
>> jint *pixels = (jint *)convert_BGRA_to_RGBA((int*)g
>> dk_pixbuf_get_pixels(screenshot), width * 4, height);
>> env->SetIntArrayRegion(data, 0, height * width, pixels);
>> g_free(pixels);
>>
>> g_object_unref(screenshot);
>> }
>>
>> Have I somehow messed up the signature? As you can see I removed one of
>> the "_" prefixes
>> to "1getScreenCapture" (which seemed to work for the other Robots) as
>> necessary because
>> the native method is no longer itself prefixed with "_".
>>
>> Thanks again.
>>
>> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> Sure, no problem. One quick comment is that a common way to solve this
>>> is by delegating to an implementation class, which would then be
>>> sub-classes.
>>>
>>>
>>> -- Kevin
>>>
>>>
>>> Michael Ennen wrote:
>>>
>>> I am not trying to be a burden here. I understand that you may not have
>>> time to hand-hold
>>> to this degree. I will try and make progress, sorry for the follow up
>>> question.
>>>
>>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen 
>>> wrote:
>>>
 How can Robot call into the implementation when it is a super class of
 the implementations?

 On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth <
 kevin.rushfo...@oracle.com> wrote:

>
>
> Michael Ennen wrote:
>
> I have a question about how to proceed with the Robot code.
>
> The base abstract Robot class is: https://github.com/brcolow
> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j
> avafx/scene/robot/Robot.java
>
> As you can see for each method, such as "getMouseX()" there is a "_"
> prefixed method
> which is abstract and a non-prefixed method:
>
> protected abstract int _getMouseX();
>
> public int getMouseX() {
> Application.checkEventThread();
> return _getMouseX();
> }
>
> I have copied this from the private Robot API.
>
> Is there a better way to do this? Would this pass review?
>
>
> Yes there are better ways to do this. No it would not pass review,
> since this would be leaking implementation into the public API.
>
> Rather than copying the public / protected methods from the internal
> package, it probably makes more sense to start with what a Robot API 
> should
> look like and then have that call into the implementation (suitably
> modified so it better matches the public 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I didn't realize "_1" is an escape character in JNI method naming and is
only
needed when the method has a "_" in its' name. Nevermind!

On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen  wrote:

> I have made quite a bit of good progress I think:
>
> https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc07b21bdcb5755
> 28d8a58eaf
>
> The public API is starting to look much cleaner:
>
> https://github.com/brcolow/openjfx/blob/master/modules/
> javafx.graphics/src/main/java/javafx/scene/robot/Robot.java
>
> Still a lot to do.
>
> Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but I
> am unsure why:
>
>   java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot.
> getScreenCapture([I)V
> at 
> javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native
> Method)
> at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor(
> GtkRobot.java:93)
>
> I have the following Java method in GtkRobot.java:
>
> @Override native protected void getScreenCapture(int x, int y, int width,
> int height, int[] data);
>
> Which is overriding the abstract method in Robot.java:
>
> protected abstract void getScreenCapture(int x, int y, int width, int
> height, int[] data);
>
> and it is implemented in GlassRobot.cpp thusly:
>
> /*
>  * Class: com_sun_glass_ui_gtk_GtkRobot
>  * Method:getScreenCapture
>  * Signature: ([I)V
>  */
> JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_
> GtkRobot_1getScreenCapture
>   (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height,
> jintArray data)
> {
> (void)obj;
>
> GdkPixbuf *screenshot, *tmp;
> GdkWindow *root_window = gdk_get_default_root_window();
>
> tmp = glass_pixbuf_from_window(root_window, x, y, width, height);
> screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0);
> g_object_unref(tmp);
>
> jint *pixels = (jint *)convert_BGRA_to_RGBA((int*)
> gdk_pixbuf_get_pixels(screenshot), width * 4, height);
> env->SetIntArrayRegion(data, 0, height * width, pixels);
> g_free(pixels);
>
> g_object_unref(screenshot);
> }
>
> Have I somehow messed up the signature? As you can see I removed one of
> the "_" prefixes
> to "1getScreenCapture" (which seemed to work for the other Robots) as
> necessary because
> the native method is no longer itself prefixed with "_".
>
> Thanks again.
>
> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Sure, no problem. One quick comment is that a common way to solve this is
>> by delegating to an implementation class, which would then be sub-classes.
>>
>>
>> -- Kevin
>>
>>
>> Michael Ennen wrote:
>>
>> I am not trying to be a burden here. I understand that you may not have
>> time to hand-hold
>> to this degree. I will try and make progress, sorry for the follow up
>> question.
>>
>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen 
>> wrote:
>>
>>> How can Robot call into the implementation when it is a super class of
>>> the implementations?
>>>
>>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>


 Michael Ennen wrote:

 I have a question about how to proceed with the Robot code.

 The base abstract Robot class is: https://github.com/brcolow
 /openjfx/blob/master/modules/javafx.graphics/src/main/java/j
 avafx/scene/robot/Robot.java

 As you can see for each method, such as "getMouseX()" there is a "_"
 prefixed method
 which is abstract and a non-prefixed method:

 protected abstract int _getMouseX();

 public int getMouseX() {
 Application.checkEventThread();
 return _getMouseX();
 }

 I have copied this from the private Robot API.

 Is there a better way to do this? Would this pass review?


 Yes there are better ways to do this. No it would not pass review,
 since this would be leaking implementation into the public API.

 Rather than copying the public / protected methods from the internal
 package, it probably makes more sense to start with what a Robot API should
 look like and then have that call into the implementation (suitably
 modified so it better matches the public API). For one thing you will then
 leave the implementation, including the per-platform code, where it belongs
 -- in glass. The Robot API can be informed by the current implementation,
 but should not be defined by it.

 -- Kevin



 Thanks very much.


 On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth <
 kevin.rushfo...@oracle.com> wrote:

> Glad you got the build working. You can post back on this thread when
> you are ready.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> Correction:
>
> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
> to buildSrc/addExports.

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I have made quite a bit of good progress I think:

https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc07b21bdcb575528d8a58eaf

The public API is starting to look much cleaner:

https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java

Still a lot to do.

Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but I
am unsure why:

  java.lang.UnsatisfiedLinkError:
com.sun.glass.ui.gtk.GtkRobot.getScreenCapture([I)V
at
javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native
Method)
at
javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor(GtkRobot.java:93)

I have the following Java method in GtkRobot.java:

@Override native protected void getScreenCapture(int x, int y, int width,
int height, int[] data);

Which is overriding the abstract method in Robot.java:

protected abstract void getScreenCapture(int x, int y, int width, int
height, int[] data);

and it is implemented in GlassRobot.cpp thusly:

/*
 * Class: com_sun_glass_ui_gtk_GtkRobot
 * Method:getScreenCapture
 * Signature: ([I)V
 */
JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_GtkRobot_1getScreenCapture
  (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height,
jintArray data)
{
(void)obj;

GdkPixbuf *screenshot, *tmp;
GdkWindow *root_window = gdk_get_default_root_window();

tmp = glass_pixbuf_from_window(root_window, x, y, width, height);
screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0);
g_object_unref(tmp);

jint *pixels = (jint
*)convert_BGRA_to_RGBA((int*)gdk_pixbuf_get_pixels(screenshot), width * 4,
height);
env->SetIntArrayRegion(data, 0, height * width, pixels);
g_free(pixels);

g_object_unref(screenshot);
}

Have I somehow messed up the signature? As you can see I removed one of the
"_" prefixes
to "1getScreenCapture" (which seemed to work for the other Robots) as
necessary because
the native method is no longer itself prefixed with "_".

Thanks again.

On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth  wrote:

> Sure, no problem. One quick comment is that a common way to solve this is
> by delegating to an implementation class, which would then be sub-classes.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> I am not trying to be a burden here. I understand that you may not have
> time to hand-hold
> to this degree. I will try and make progress, sorry for the follow up
> question.
>
> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen 
> wrote:
>
>> How can Robot call into the implementation when it is a super class of
>> the implementations?
>>
>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>>
>>>
>>> Michael Ennen wrote:
>>>
>>> I have a question about how to proceed with the Robot code.
>>>
>>> The base abstract Robot class is: https://github.com/brcolow
>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j
>>> avafx/scene/robot/Robot.java
>>>
>>> As you can see for each method, such as "getMouseX()" there is a "_"
>>> prefixed method
>>> which is abstract and a non-prefixed method:
>>>
>>> protected abstract int _getMouseX();
>>>
>>> public int getMouseX() {
>>> Application.checkEventThread();
>>> return _getMouseX();
>>> }
>>>
>>> I have copied this from the private Robot API.
>>>
>>> Is there a better way to do this? Would this pass review?
>>>
>>>
>>> Yes there are better ways to do this. No it would not pass review, since
>>> this would be leaking implementation into the public API.
>>>
>>> Rather than copying the public / protected methods from the internal
>>> package, it probably makes more sense to start with what a Robot API should
>>> look like and then have that call into the implementation (suitably
>>> modified so it better matches the public API). For one thing you will then
>>> leave the implementation, including the per-platform code, where it belongs
>>> -- in glass. The Robot API can be informed by the current implementation,
>>> but should not be defined by it.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Thanks very much.
>>>
>>>
>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>
 Glad you got the build working. You can post back on this thread when
 you are ready.


 -- Kevin


 Michael Ennen wrote:

 Correction:

 Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
 to buildSrc/addExports.

 For posterity :)

 On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen 
 wrote:

> Ah, indeed, missed adding "--add-opens 
> javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
> to buildSrc/addExports.
> Thanks for the guidance on that.
>
> I will continue to work on this in the GitHub repo and polish it up
> (add javadocs, better method signatures, etc.) and

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

Sure, no problem. One quick comment is that a common way to solve this 
is by delegating to an implementation class, which would then be 
sub-classes.


-- Kevin


Michael Ennen wrote:
I am not trying to be a burden here. I understand that you may not 
have time to hand-hold
to this degree. I will try and make progress, sorry for the follow up 
question.


On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen > wrote:


How can Robot call into the implementation when it is a super
class of the implementations?

On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth
>
wrote:



Michael Ennen wrote:

I have a question about how to proceed with the Robot code.

The base abstract Robot class
is: 
https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java



As you can see for each method, such as "getMouseX()" there
is a "_" prefixed method
which is abstract and a non-prefixed method:

protected abstract int _getMouseX();

public int getMouseX() {
Application.checkEventThread();
return _getMouseX();
}

I have copied this from the private Robot API.

Is there a better way to do this? Would this pass review?


Yes there are better ways to do this. No it would not pass
review, since this would be leaking implementation into the
public API.

Rather than copying the public / protected methods from the
internal package, it probably makes more sense to start with
what a Robot API should look like and then have that call into
the implementation (suitably modified so it better matches the
public API). For one thing you will then leave the
implementation, including the per-platform code, where it
belongs -- in glass. The Robot API can be informed by the
current implementation, but should not be defined by it.

-- Kevin




Thanks very much.


On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth
> wrote:

Glad you got the build working. You can post back on this
thread when you are ready.


-- Kevin


Michael Ennen wrote:

Correction:

Adding ""--add-exports
javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to
buildSrc/addExports.

For posterity :)

On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen
> wrote:

Ah, indeed, missed adding "--add-opens
javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to
buildSrc/addExports.
Thanks for the guidance on that.

I will continue to work on this in the GitHub repo
and polish it up (add javadocs, better method
signatures, etc.) and 
even plan on maybe improving the underlying native

Robot implementations (for example fixing/improving the
way color profiles are handled for MacRobot).

I will also take a look at "fixing" JemmyFX to use
the new public API (as well as any other place in
the JavaFX code
base that does).

I was expecting that JDK 11 would be the appropriate
time frame, especially because it will be the
release where
private APIs will be totally inaccessible, correct?

After I get it in a reasonable state should I post
back on this mailing list thread or what would be
the appropriate
way?

Thanks Kevin.

On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth
> wrote:

This is a limitation of the the way
--patch-modules works. You will need to add an
entry in:

buildSrc/addExports

Btw, as for the proposal itself, this might need
to be a JEP depending on the scope. In any case,
it could be considered in the JDK 11 time frame,
but there are several things that need to be
worked out before making Robot a public API,
including the fact that the JemmyFX framework in
the openjfx/jfx/tests directory uses Robot. Once
 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I am not trying to be a burden here. I understand that you may not have
time to hand-hold
to this degree. I will try and make progress, sorry for the follow up
question.

On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen  wrote:

> How can Robot call into the implementation when it is a super class of the
> implementations?
>
> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>>
>>
>> Michael Ennen wrote:
>>
>> I have a question about how to proceed with the Robot code.
>>
>> The base abstract Robot class is: https://github.com/brcolow
>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/
>> javafx/scene/robot/Robot.java
>>
>> As you can see for each method, such as "getMouseX()" there is a "_"
>> prefixed method
>> which is abstract and a non-prefixed method:
>>
>> protected abstract int _getMouseX();
>>
>> public int getMouseX() {
>> Application.checkEventThread();
>> return _getMouseX();
>> }
>>
>> I have copied this from the private Robot API.
>>
>> Is there a better way to do this? Would this pass review?
>>
>>
>> Yes there are better ways to do this. No it would not pass review, since
>> this would be leaking implementation into the public API.
>>
>> Rather than copying the public / protected methods from the internal
>> package, it probably makes more sense to start with what a Robot API should
>> look like and then have that call into the implementation (suitably
>> modified so it better matches the public API). For one thing you will then
>> leave the implementation, including the per-platform code, where it belongs
>> -- in glass. The Robot API can be informed by the current implementation,
>> but should not be defined by it.
>>
>> -- Kevin
>>
>>
>>
>> Thanks very much.
>>
>>
>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> Glad you got the build working. You can post back on this thread when
>>> you are ready.
>>>
>>>
>>> -- Kevin
>>>
>>>
>>> Michael Ennen wrote:
>>>
>>> Correction:
>>>
>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
>>> to buildSrc/addExports.
>>>
>>> For posterity :)
>>>
>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen 
>>> wrote:
>>>
 Ah, indeed, missed adding "--add-opens 
 javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
 to buildSrc/addExports.
 Thanks for the guidance on that.

 I will continue to work on this in the GitHub repo and polish it up
 (add javadocs, better method signatures, etc.) and
 even plan on maybe improving the underlying native Robot
 implementations (for example fixing/improving the
 way color profiles are handled for MacRobot).

 I will also take a look at "fixing" JemmyFX to use the new public API
 (as well as any other place in the JavaFX code
 base that does).

 I was expecting that JDK 11 would be the appropriate time frame,
 especially because it will be the release where
 private APIs will be totally inaccessible, correct?

 After I get it in a reasonable state should I post back on this mailing
 list thread or what would be the appropriate
 way?

 Thanks Kevin.

 On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth <
 kevin.rushfo...@oracle.com> wrote:

> This is a limitation of the the way --patch-modules works. You will
> need to add an entry in:
>
> buildSrc/addExports
>
> Btw, as for the proposal itself, this might need to be a JEP depending
> on the scope. In any case, it could be considered in the JDK 11 time 
> frame,
> but there are several things that need to be worked out before making 
> Robot
> a public API, including the fact that the JemmyFX framework in the
> openjfx/jfx/tests directory uses Robot. Once you get a working prototype,
> it would be interesting to discuss it in more detail.
>
> -- Kevin
>
>
>
> Michael Ennen wrote:
>
> Currently I am stuck with tests not being able to see the new
> "javafx.scene.robot" module:
>
>
>
> Task :systemTests:compileTestJava
>
>
> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
> error: package javafx.scene.robot is not visible
> import javafx.scene.robot.Robot;
>^
>   (package javafx.scene.robot is declared in module javafx.graphics, which
> does not export it)
> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33:
> error: package javafx.scene.robot is not visible
> import javafx.scene.robot.Robot;
>
> I have added:
>
> exports javafx.scene.robot;
>
> to: modules/javafx.graphics/src/main/java/module-info.java
>
> But this does not seem to be enough.
>
> On Sun, Dec 3, 2017 at 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

How can Robot call into the implementation when it is a super class of the
implementations?

On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth  wrote:

>
>
> Michael Ennen wrote:
>
> I have a question about how to proceed with the Robot code.
>
> The base abstract Robot class is: https://github.com/
> brcolow/openjfx/blob/master/modules/javafx.graphics/src/
> main/java/javafx/scene/robot/Robot.java
>
> As you can see for each method, such as "getMouseX()" there is a "_"
> prefixed method
> which is abstract and a non-prefixed method:
>
> protected abstract int _getMouseX();
>
> public int getMouseX() {
> Application.checkEventThread();
> return _getMouseX();
> }
>
> I have copied this from the private Robot API.
>
> Is there a better way to do this? Would this pass review?
>
>
> Yes there are better ways to do this. No it would not pass review, since
> this would be leaking implementation into the public API.
>
> Rather than copying the public / protected methods from the internal
> package, it probably makes more sense to start with what a Robot API should
> look like and then have that call into the implementation (suitably
> modified so it better matches the public API). For one thing you will then
> leave the implementation, including the per-platform code, where it belongs
> -- in glass. The Robot API can be informed by the current implementation,
> but should not be defined by it.
>
> -- Kevin
>
>
>
> Thanks very much.
>
>
> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Glad you got the build working. You can post back on this thread when you
>> are ready.
>>
>>
>> -- Kevin
>>
>>
>> Michael Ennen wrote:
>>
>> Correction:
>>
>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
>> to buildSrc/addExports.
>>
>> For posterity :)
>>
>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen 
>> wrote:
>>
>>> Ah, indeed, missed adding "--add-opens 
>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
>>> to buildSrc/addExports.
>>> Thanks for the guidance on that.
>>>
>>> I will continue to work on this in the GitHub repo and polish it up (add
>>> javadocs, better method signatures, etc.) and
>>> even plan on maybe improving the underlying native Robot implementations
>>> (for example fixing/improving the
>>> way color profiles are handled for MacRobot).
>>>
>>> I will also take a look at "fixing" JemmyFX to use the new public API
>>> (as well as any other place in the JavaFX code
>>> base that does).
>>>
>>> I was expecting that JDK 11 would be the appropriate time frame,
>>> especially because it will be the release where
>>> private APIs will be totally inaccessible, correct?
>>>
>>> After I get it in a reasonable state should I post back on this mailing
>>> list thread or what would be the appropriate
>>> way?
>>>
>>> Thanks Kevin.
>>>
>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>
 This is a limitation of the the way --patch-modules works. You will
 need to add an entry in:

 buildSrc/addExports

 Btw, as for the proposal itself, this might need to be a JEP depending
 on the scope. In any case, it could be considered in the JDK 11 time frame,
 but there are several things that need to be worked out before making Robot
 a public API, including the fact that the JemmyFX framework in the
 openjfx/jfx/tests directory uses Robot. Once you get a working prototype,
 it would be interesting to discuss it in more detail.

 -- Kevin



 Michael Ennen wrote:

 Currently I am stuck with tests not being able to see the new
 "javafx.scene.robot" module:



 Task :systemTests:compileTestJava


 C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
 error: package javafx.scene.robot is not visible
 import javafx.scene.robot.Robot;
^
   (package javafx.scene.robot is declared in module javafx.graphics, which
 does not export it)
 C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33:
 error: package javafx.scene.robot is not visible
 import javafx.scene.robot.Robot;

 I have added:

 exports javafx.scene.robot;

 to: modules/javafx.graphics/src/main/java/module-info.java

 But this does not seem to be enough.

 On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen  
  wrote:



 I am still working on all the necessary changes to actually allow openjfx
 to compile.
 Tons to learn in that arena and I know the code as it is written won't
 totally work.
 For example one can no longer:

 #include "com_sun_glass_ui_Robot.h"

 as in 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

Michael Ennen wrote:

I have a question about how to proceed with the Robot code.

The base abstract Robot class 
is: https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java


As you can see for each method, such as "getMouseX()" there is a "_" 
prefixed method

which is abstract and a non-prefixed method:

protected abstract int _getMouseX();

public int getMouseX() {
Application.checkEventThread();
return _getMouseX();
}

I have copied this from the private Robot API.

Is there a better way to do this? Would this pass review?


Yes there are better ways to do this. No it would not pass review, since 
this would be leaking implementation into the public API.


Rather than copying the public / protected methods from the internal 
package, it probably makes more sense to start with what a Robot API 
should look like and then have that call into the implementation 
(suitably modified so it better matches the public API). For one thing 
you will then leave the implementation, including the per-platform code, 
where it belongs -- in glass. The Robot API can be informed by the 
current implementation, but should not be defined by it.


-- Kevin



Thanks very much.


On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth 
> wrote:


Glad you got the build working. You can post back on this thread
when you are ready.


-- Kevin


Michael Ennen wrote:

Correction:

Adding ""--add-exports
javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to
buildSrc/addExports.

For posterity :)

On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen
> wrote:

Ah, indeed, missed adding "--add-opens
javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to
buildSrc/addExports.
Thanks for the guidance on that.

I will continue to work on this in the GitHub repo and polish
it up (add javadocs, better method signatures, etc.) and 
even plan on maybe improving the underlying native Robot

implementations (for example fixing/improving the
way color profiles are handled for MacRobot).

I will also take a look at "fixing" JemmyFX to use the new
public API (as well as any other place in the JavaFX code
base that does).

I was expecting that JDK 11 would be the appropriate time
frame, especially because it will be the release where
private APIs will be totally inaccessible, correct?

After I get it in a reasonable state should I post back on
this mailing list thread or what would be the appropriate
way?

Thanks Kevin.

On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth
> wrote:

This is a limitation of the the way --patch-modules
works. You will need to add an entry in:

buildSrc/addExports

Btw, as for the proposal itself, this might need to be a
JEP depending on the scope. In any case, it could be
considered in the JDK 11 time frame, but there are
several things that need to be worked out before making
Robot a public API, including the fact that the JemmyFX
framework in the openjfx/jfx/tests directory uses Robot.
Once you get a working prototype, it would be interesting
to discuss it in more detail.

-- Kevin



Michael Ennen wrote:

Currently I am stuck with tests not being able to see the new
"javafx.scene.robot" module:

  

Task :systemTests:compileTestJava



C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
error: package javafx.scene.robot is not visible
import javafx.scene.robot.Robot;
   ^
  (package javafx.scene.robot is declared in module 
javafx.graphics, which
does not export it)

C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33:
error: package javafx.scene.robot is not visible
import javafx.scene.robot.Robot;

I have added:

exports javafx.scene.robot;

to: modules/javafx.graphics/src/main/java/module-info.java

But this does not seem to be enough.

On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen  
 wrote:

  

I am still working on all the necessary changes to actually allow 
openjfx
to compile.
Tons to learn in that arena and I know the code as it is written 
won't
  

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I have a question about how to proceed with the Robot code.

The base abstract Robot class is:
https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java

As you can see for each method, such as "getMouseX()" there is a "_"
prefixed method
which is abstract and a non-prefixed method:

protected abstract int _getMouseX();

public int getMouseX() {
Application.checkEventThread();
return _getMouseX();
}

I have copied this from the private Robot API.

Is there a better way to do this? Would this pass review?

Thanks very much.


On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth 
wrote:

> Glad you got the build working. You can post back on this thread when you
> are ready.
>
>
> -- Kevin
>
>
> Michael Ennen wrote:
>
> Correction:
>
> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to
> buildSrc/addExports.
>
> For posterity :)
>
> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen 
> wrote:
>
>> Ah, indeed, missed adding "--add-opens 
>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
>> to buildSrc/addExports.
>> Thanks for the guidance on that.
>>
>> I will continue to work on this in the GitHub repo and polish it up (add
>> javadocs, better method signatures, etc.) and
>> even plan on maybe improving the underlying native Robot implementations
>> (for example fixing/improving the
>> way color profiles are handled for MacRobot).
>>
>> I will also take a look at "fixing" JemmyFX to use the new public API (as
>> well as any other place in the JavaFX code
>> base that does).
>>
>> I was expecting that JDK 11 would be the appropriate time frame,
>> especially because it will be the release where
>> private APIs will be totally inaccessible, correct?
>>
>> After I get it in a reasonable state should I post back on this mailing
>> list thread or what would be the appropriate
>> way?
>>
>> Thanks Kevin.
>>
>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> This is a limitation of the the way --patch-modules works. You will need
>>> to add an entry in:
>>>
>>> buildSrc/addExports
>>>
>>> Btw, as for the proposal itself, this might need to be a JEP depending
>>> on the scope. In any case, it could be considered in the JDK 11 time frame,
>>> but there are several things that need to be worked out before making Robot
>>> a public API, including the fact that the JemmyFX framework in the
>>> openjfx/jfx/tests directory uses Robot. Once you get a working prototype,
>>> it would be interesting to discuss it in more detail.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Michael Ennen wrote:
>>>
>>> Currently I am stuck with tests not being able to see the new
>>> "javafx.scene.robot" module:
>>>
>>>
>>>
>>> Task :systemTests:compileTestJava
>>>
>>>
>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
>>> error: package javafx.scene.robot is not visible
>>> import javafx.scene.robot.Robot;
>>>^
>>>   (package javafx.scene.robot is declared in module javafx.graphics, which
>>> does not export it)
>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33:
>>> error: package javafx.scene.robot is not visible
>>> import javafx.scene.robot.Robot;
>>>
>>> I have added:
>>>
>>> exports javafx.scene.robot;
>>>
>>> to: modules/javafx.graphics/src/main/java/module-info.java
>>>
>>> But this does not seem to be enough.
>>>
>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen  
>>>  wrote:
>>>
>>>
>>>
>>> I am still working on all the necessary changes to actually allow openjfx
>>> to compile.
>>> Tons to learn in that arena and I know the code as it is written won't
>>> totally work.
>>> For example one can no longer:
>>>
>>> #include "com_sun_glass_ui_Robot.h"
>>>
>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp
>>>
>>> But I am not sure how those headers are generated and if I can just simply
>>> change
>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt).
>>>
>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen  
>>> 
>>> wrote:
>>>
>>>
>>>
>>> I have created a (small) proposal (building on the work of Benjamin
>>> Gudehaus) about moving some classes in to the public API so that TestFX (a
>>> JavaFX UI testing framework) can continue to work with future JDK releases.
>>> The somewhat nicely formatted proposal can be found as a Github gist:
>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19
>>>
>>> All suggested changes can be found by using Github Compare View:
>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5
>>> e1f4f1cb8f20430feaa53b6...master
>>>
>>> But I have copied it to this email for convenience:
>>>
>>> --- PROPOSAL 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

Glad you got the build working. You can post back on this thread when 
you are ready.


-- Kevin


Michael Ennen wrote:

Correction:

Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" 
to buildSrc/addExports.


For posterity :)

On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen > wrote:


Ah, indeed, missed adding "--add-opens
javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to
buildSrc/addExports.
Thanks for the guidance on that.

I will continue to work on this in the GitHub repo and polish it
up (add javadocs, better method signatures, etc.) and 
even plan on maybe improving the underlying native Robot

implementations (for example fixing/improving the
way color profiles are handled for MacRobot).

I will also take a look at "fixing" JemmyFX to use the new public
API (as well as any other place in the JavaFX code
base that does).

I was expecting that JDK 11 would be the appropriate time frame,
especially because it will be the release where
private APIs will be totally inaccessible, correct?

After I get it in a reasonable state should I post back on this
mailing list thread or what would be the appropriate
way?

Thanks Kevin.

On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth
>
wrote:

This is a limitation of the the way --patch-modules works. You
will need to add an entry in:

buildSrc/addExports

Btw, as for the proposal itself, this might need to be a JEP
depending on the scope. In any case, it could be considered in
the JDK 11 time frame, but there are several things that need
to be worked out before making Robot a public API, including
the fact that the JemmyFX framework in the openjfx/jfx/tests
directory uses Robot. Once you get a working prototype, it
would be interesting to discuss it in more detail.

-- Kevin



Michael Ennen wrote:

Currently I am stuck with tests not being able to see the new
"javafx.scene.robot" module:

  

Task :systemTests:compileTestJava



C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
error: package javafx.scene.robot is not visible
import javafx.scene.robot.Robot;
   ^
  (package javafx.scene.robot is declared in module javafx.graphics, 
which
does not export it)

C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33:
error: package javafx.scene.robot is not visible
import javafx.scene.robot.Robot;

I have added:

exports javafx.scene.robot;

to: modules/javafx.graphics/src/main/java/module-info.java

But this does not seem to be enough.

On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen  
 wrote:

  

I am still working on all the necessary changes to actually allow 
openjfx
to compile.
Tons to learn in that arena and I know the code as it is written won't
totally work.
For example one can no longer:

#include "com_sun_glass_ui_Robot.h"

as in 
openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp

But I am not sure how those headers are generated and if I can just 
simply
change
it to "#include javafx_scene_robot_Robot.h" (which I very much doubt).

On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen  

wrote:



I have created a (small) proposal (building on the work of Benjamin
Gudehaus) about moving some classes in to the public API so that TestFX 
(a
JavaFX UI testing framework) can continue to work with future JDK 
releases.
The somewhat nicely formatted proposal can be found as a Github gist:

https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 


All suggested changes can be found by using Github Compare View:

https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 

e1f4f1cb8f20430feaa53b6...master

But I have copied it to this email for convenience:

--- PROPOSAL ---

TestFX, the JavaFX GUI testing framework currently requires 4 (four)
classes that are part of the JDK's private API. They are:

[com.sun.glass.ui.Application](http://hg.openjdk.java.net/op
enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Correction:

Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to
buildSrc/addExports.

For posterity :)

On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen  wrote:

> Ah, indeed, missed adding "--add-opens 
> javafx.graphics/javafx.scene.robot=ALL-UNNAMED"
> to buildSrc/addExports.
> Thanks for the guidance on that.
>
> I will continue to work on this in the GitHub repo and polish it up (add
> javadocs, better method signatures, etc.) and
> even plan on maybe improving the underlying native Robot implementations
> (for example fixing/improving the
> way color profiles are handled for MacRobot).
>
> I will also take a look at "fixing" JemmyFX to use the new public API (as
> well as any other place in the JavaFX code
> base that does).
>
> I was expecting that JDK 11 would be the appropriate time frame,
> especially because it will be the release where
> private APIs will be totally inaccessible, correct?
>
> After I get it in a reasonable state should I post back on this mailing
> list thread or what would be the appropriate
> way?
>
> Thanks Kevin.
>
> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> This is a limitation of the the way --patch-modules works. You will need
>> to add an entry in:
>>
>> buildSrc/addExports
>>
>> Btw, as for the proposal itself, this might need to be a JEP depending on
>> the scope. In any case, it could be considered in the JDK 11 time frame,
>> but there are several things that need to be worked out before making Robot
>> a public API, including the fact that the JemmyFX framework in the
>> openjfx/jfx/tests directory uses Robot. Once you get a working prototype,
>> it would be interesting to discuss it in more detail.
>>
>> -- Kevin
>>
>>
>>
>> Michael Ennen wrote:
>>
>> Currently I am stuck with tests not being able to see the new
>> "javafx.scene.robot" module:
>>
>>
>>
>> Task :systemTests:compileTestJava
>>
>>
>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
>> error: package javafx.scene.robot is not visible
>> import javafx.scene.robot.Robot;
>>^
>>   (package javafx.scene.robot is declared in module javafx.graphics, which
>> does not export it)
>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33:
>> error: package javafx.scene.robot is not visible
>> import javafx.scene.robot.Robot;
>>
>> I have added:
>>
>> exports javafx.scene.robot;
>>
>> to: modules/javafx.graphics/src/main/java/module-info.java
>>
>> But this does not seem to be enough.
>>
>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen  
>>  wrote:
>>
>>
>>
>> I am still working on all the necessary changes to actually allow openjfx
>> to compile.
>> Tons to learn in that arena and I know the code as it is written won't
>> totally work.
>> For example one can no longer:
>>
>> #include "com_sun_glass_ui_Robot.h"
>>
>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp
>>
>> But I am not sure how those headers are generated and if I can just simply
>> change
>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt).
>>
>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen  
>> 
>> wrote:
>>
>>
>>
>> I have created a (small) proposal (building on the work of Benjamin
>> Gudehaus) about moving some classes in to the public API so that TestFX (a
>> JavaFX UI testing framework) can continue to work with future JDK releases.
>> The somewhat nicely formatted proposal can be found as a Github gist:
>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19
>>
>> All suggested changes can be found by using Github Compare View:
>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5
>> e1f4f1cb8f20430feaa53b6...master
>>
>> But I have copied it to this email for convenience:
>>
>> --- PROPOSAL ---
>>
>> TestFX, the JavaFX GUI testing framework currently requires 4 (four)
>> classes that are part of the JDK's private API. They are:
>>
>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op
>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/
>> java/com/sun/glass/ui/Application.java)
>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx
>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/
>> com/sun/glass/ui/Pixels.java)
>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/
>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com
>> /sun/glass/ui/Robot.java)
>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx.
>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java 
>> 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Ah, indeed, missed adding "--add-opens
javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to buildSrc/addExports.
Thanks for the guidance on that.

I will continue to work on this in the GitHub repo and polish it up (add
javadocs, better method signatures, etc.) and
even plan on maybe improving the underlying native Robot implementations
(for example fixing/improving the
way color profiles are handled for MacRobot).

I will also take a look at "fixing" JemmyFX to use the new public API (as
well as any other place in the JavaFX code
base that does).

I was expecting that JDK 11 would be the appropriate time frame, especially
because it will be the release where
private APIs will be totally inaccessible, correct?

After I get it in a reasonable state should I post back on this mailing
list thread or what would be the appropriate
way?

Thanks Kevin.

On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth 
wrote:

> This is a limitation of the the way --patch-modules works. You will need
> to add an entry in:
>
> buildSrc/addExports
>
> Btw, as for the proposal itself, this might need to be a JEP depending on
> the scope. In any case, it could be considered in the JDK 11 time frame,
> but there are several things that need to be worked out before making Robot
> a public API, including the fact that the JemmyFX framework in the
> openjfx/jfx/tests directory uses Robot. Once you get a working prototype,
> it would be interesting to discuss it in more detail.
>
> -- Kevin
>
>
>
> Michael Ennen wrote:
>
> Currently I am stuck with tests not being able to see the new
> "javafx.scene.robot" module:
>
>
>
> Task :systemTests:compileTestJava
>
>
> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
> error: package javafx.scene.robot is not visible
> import javafx.scene.robot.Robot;
>^
>   (package javafx.scene.robot is declared in module javafx.graphics, which
> does not export it)
> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33:
> error: package javafx.scene.robot is not visible
> import javafx.scene.robot.Robot;
>
> I have added:
>
> exports javafx.scene.robot;
>
> to: modules/javafx.graphics/src/main/java/module-info.java
>
> But this does not seem to be enough.
>
> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen  
>  wrote:
>
>
>
> I am still working on all the necessary changes to actually allow openjfx
> to compile.
> Tons to learn in that arena and I know the code as it is written won't
> totally work.
> For example one can no longer:
>
> #include "com_sun_glass_ui_Robot.h"
>
> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp
>
> But I am not sure how those headers are generated and if I can just simply
> change
> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt).
>
> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen  
> 
> wrote:
>
>
>
> I have created a (small) proposal (building on the work of Benjamin
> Gudehaus) about moving some classes in to the public API so that TestFX (a
> JavaFX UI testing framework) can continue to work with future JDK releases.
> The somewhat nicely formatted proposal can be found as a Github gist:
> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19
>
> All suggested changes can be found by using Github Compare View:
> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5
> e1f4f1cb8f20430feaa53b6...master
>
> But I have copied it to this email for convenience:
>
> --- PROPOSAL ---
>
> TestFX, the JavaFX GUI testing framework currently requires 4 (four)
> classes that are part of the JDK's private API. They are:
>
> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op
> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/
> java/com/sun/glass/ui/Application.java)
> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx
> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/
> com/sun/glass/ui/Pixels.java)
> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/
> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com
> /sun/glass/ui/Robot.java)
> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx.
> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java 
> )
>
> In order to compile the project with Java 9, we use the following flags:
>
> ```sh
> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx
> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx
> ```
>
> If the --add-exports flags are disabled in a future Java release TestFX
> will require these four classes 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Kevin Rushforth]

This is a limitation of the the way --patch-modules works. You will need 
to add an entry in:


buildSrc/addExports

Btw, as for the proposal itself, this might need to be a JEP depending 
on the scope. In any case, it could be considered in the JDK 11 time 
frame, but there are several things that need to be worked out before 
making Robot a public API, including the fact that the JemmyFX framework 
in the openjfx/jfx/tests directory uses Robot. Once you get a working 
prototype, it would be interesting to discuss it in more detail.


-- Kevin


Michael Ennen wrote:

Currently I am stuck with tests not being able to see the new
"javafx.scene.robot" module:

  

Task :systemTests:compileTestJava


C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
error: package javafx.scene.robot is not visible
import javafx.scene.robot.Robot;
   ^
  (package javafx.scene.robot is declared in module javafx.graphics, which
does not export it)
C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33:
error: package javafx.scene.robot is not visible
import javafx.scene.robot.Robot;

I have added:

exports javafx.scene.robot;

to: modules/javafx.graphics/src/main/java/module-info.java

But this does not seem to be enough.

On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen  wrote:

  

I am still working on all the necessary changes to actually allow openjfx
to compile.
Tons to learn in that arena and I know the code as it is written won't
totally work.
For example one can no longer:

#include "com_sun_glass_ui_Robot.h"

as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp

But I am not sure how those headers are generated and if I can just simply
change
it to "#include javafx_scene_robot_Robot.h" (which I very much doubt).

On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen 
wrote:



I have created a (small) proposal (building on the work of Benjamin
Gudehaus) about moving some classes in to the public API so that TestFX (a
JavaFX UI testing framework) can continue to work with future JDK releases.
The somewhat nicely formatted proposal can be found as a Github gist:

https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19

All suggested changes can be found by using Github Compare View:

https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5
e1f4f1cb8f20430feaa53b6...master

But I have copied it to this email for convenience:

--- PROPOSAL ---

TestFX, the JavaFX GUI testing framework currently requires 4 (four)
classes that are part of the JDK's private API. They are:

[com.sun.glass.ui.Application](http://hg.openjdk.java.net/op
enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/
java/com/sun/glass/ui/Application.java)
[com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx
/10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/
com/sun/glass/ui/Pixels.java)
[com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/
10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com
/sun/glass/ui/Robot.java)
[com.sun.javafx.application.ParametersImpl](http://hg.openjd
k.java.net/openjfx/10-dev/rt/file/tip/modules/javafx.
graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java)

In order to compile the project with Java 9, we use the following flags:

```sh
--add-exports javafx.graphics/com.sun.glass.ui=org.testfx
--add-exports javafx.graphics/com.sun.javafx.application=org.testfx
```

If the --add-exports flags are disabled in a future Java release TestFX
will require these four classes to be moved into the public API to
continue working.

While these classes are probably not very useful for applications to use
directly, any JavaFX application wanting to write UI tests will most
likely
use TestFX and thus they will indirectly be using these classes.

JavaFX internal tests also use these classes for essentially the same
purpose (UI tests).

### Details of Usage For Each Private API Class

 com.sun.javafx.application.ParametersImpl

# TestFX Usage

```java
ParametersImpl parameters = new ParametersImpl(applicationArgs);
ParametersImpl.registerParameters(application, parameters);
```

The parameters are set on a constructed Application.

# Suggested Public API Replacement

`javafx.application.Application`:

```java
/**
 * Sets the parameters for this Application.
 *
 * 
 * NOTE: this method should not be called from the Application
constructor,
 * as it will return null. It may be called in the init() method or any
 * time after that.
 * 
 *
 * @param parameters the parameters to set for this Application
 */
public final Parameters setParameters(String... parameters) {
ParametersImpl parameters = new ParametersImpl(parameters);
ParametersImpl.registerParameters(this, parameters);
}
```

 com.sun.glass.ui.Application

# 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

Currently I am stuck with tests not being able to see the new
"javafx.scene.robot" module:

> Task :systemTests:compileTestJava
C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34:
error: package javafx.scene.robot is not visible
import javafx.scene.robot.Robot;
   ^
  (package javafx.scene.robot is declared in module javafx.graphics, which
does not export it)
C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33:
error: package javafx.scene.robot is not visible
import javafx.scene.robot.Robot;

I have added:

exports javafx.scene.robot;

to: modules/javafx.graphics/src/main/java/module-info.java

But this does not seem to be enough.

On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen  wrote:

> I am still working on all the necessary changes to actually allow openjfx
> to compile.
> Tons to learn in that arena and I know the code as it is written won't
> totally work.
> For example one can no longer:
>
> #include "com_sun_glass_ui_Robot.h"
>
> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp
>
> But I am not sure how those headers are generated and if I can just simply
> change
> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt).
>
> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen 
> wrote:
>
>> I have created a (small) proposal (building on the work of Benjamin
>> Gudehaus) about moving some classes in to the public API so that TestFX (a
>> JavaFX UI testing framework) can continue to work with future JDK releases.
>> The somewhat nicely formatted proposal can be found as a Github gist:
>>
>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19
>>
>> All suggested changes can be found by using Github Compare View:
>>
>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5
>> e1f4f1cb8f20430feaa53b6...master
>>
>> But I have copied it to this email for convenience:
>>
>> --- PROPOSAL ---
>>
>> TestFX, the JavaFX GUI testing framework currently requires 4 (four)
>> classes that are part of the JDK's private API. They are:
>>
>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op
>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/
>> java/com/sun/glass/ui/Application.java)
>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx
>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/
>> com/sun/glass/ui/Pixels.java)
>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/
>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com
>> /sun/glass/ui/Robot.java)
>> [com.sun.javafx.application.ParametersImpl](http://hg.openjd
>> k.java.net/openjfx/10-dev/rt/file/tip/modules/javafx.
>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java)
>>
>> In order to compile the project with Java 9, we use the following flags:
>>
>> ```sh
>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx
>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx
>> ```
>>
>> If the --add-exports flags are disabled in a future Java release TestFX
>> will require these four classes to be moved into the public API to
>> continue working.
>>
>> While these classes are probably not very useful for applications to use
>> directly, any JavaFX application wanting to write UI tests will most
>> likely
>> use TestFX and thus they will indirectly be using these classes.
>>
>> JavaFX internal tests also use these classes for essentially the same
>> purpose (UI tests).
>>
>> ### Details of Usage For Each Private API Class
>>
>>  com.sun.javafx.application.ParametersImpl
>>
>> # TestFX Usage
>>
>> ```java
>> ParametersImpl parameters = new ParametersImpl(applicationArgs);
>> ParametersImpl.registerParameters(application, parameters);
>> ```
>>
>> The parameters are set on a constructed Application.
>>
>> # Suggested Public API Replacement
>>
>> `javafx.application.Application`:
>>
>> ```java
>> /**
>>  * Sets the parameters for this Application.
>>  *
>>  * 
>>  * NOTE: this method should not be called from the Application
>> constructor,
>>  * as it will return null. It may be called in the init() method or any
>>  * time after that.
>>  * 
>>  *
>>  * @param parameters the parameters to set for this Application
>>  */
>> public final Parameters setParameters(String... parameters) {
>> ParametersImpl parameters = new ParametersImpl(parameters);
>> ParametersImpl.registerParameters(this, parameters);
>> }
>> ```
>>
>>  com.sun.glass.ui.Application
>>
>> # TestFX Usage
>>
>> ```java
>> return Application.GetApplication().createRobot();
>> ```
>>
>> The Application class is used to instantiate a Robot.
>>
>> # Suggested Public API Replacement
>>
>> `javafx.application.Application`:
>>
>> https://github.com/brcolow/openjfx/blob/master/modules/javaf
>> 

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

[Michael Ennen]

I am still working on all the necessary changes to actually allow openjfx
to compile.
Tons to learn in that arena and I know the code as it is written won't
totally work.
For example one can no longer:

#include "com_sun_glass_ui_Robot.h"

as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp

But I am not sure how those headers are generated and if I can just simply
change
it to "#include javafx_scene_robot_Robot.h" (which I very much doubt).

On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen  wrote:

> I have created a (small) proposal (building on the work of Benjamin
> Gudehaus) about moving some classes in to the public API so that TestFX (a
> JavaFX UI testing framework) can continue to work with future JDK releases.
> The somewhat nicely formatted proposal can be found as a Github gist:
>
> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19
>
> All suggested changes can be found by using Github Compare View:
>
> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5e1f4f1cb8f204
> 30feaa53b6...master
>
> But I have copied it to this email for convenience:
>
> --- PROPOSAL ---
>
> TestFX, the JavaFX GUI testing framework currently requires 4 (four)
> classes that are part of the JDK's private API. They are:
>
> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/
> openjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/
> main/java/com/sun/glass/ui/Application.java)
> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/
> openjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/
> main/java/com/sun/glass/ui/Pixels.java)
> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/
> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/
> com/sun/glass/ui/Robot.java)
> [com.sun.javafx.application.ParametersImpl](http://hg.
> openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/
> javafx.graphics/src/main/java/com/sun/javafx/application/
> ParametersImpl.java)
>
> In order to compile the project with Java 9, we use the following flags:
>
> ```sh
> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx
> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx
> ```
>
> If the --add-exports flags are disabled in a future Java release TestFX
> will require these four classes to be moved into the public API to
> continue working.
>
> While these classes are probably not very useful for applications to use
> directly, any JavaFX application wanting to write UI tests will most likely
> use TestFX and thus they will indirectly be using these classes.
>
> JavaFX internal tests also use these classes for essentially the same
> purpose (UI tests).
>
> ### Details of Usage For Each Private API Class
>
>  com.sun.javafx.application.ParametersImpl
>
> # TestFX Usage
>
> ```java
> ParametersImpl parameters = new ParametersImpl(applicationArgs);
> ParametersImpl.registerParameters(application, parameters);
> ```
>
> The parameters are set on a constructed Application.
>
> # Suggested Public API Replacement
>
> `javafx.application.Application`:
>
> ```java
> /**
>  * Sets the parameters for this Application.
>  *
>  * 
>  * NOTE: this method should not be called from the Application constructor,
>  * as it will return null. It may be called in the init() method or any
>  * time after that.
>  * 
>  *
>  * @param parameters the parameters to set for this Application
>  */
> public final Parameters setParameters(String... parameters) {
> ParametersImpl parameters = new ParametersImpl(parameters);
> ParametersImpl.registerParameters(this, parameters);
> }
> ```
>
>  com.sun.glass.ui.Application
>
> # TestFX Usage
>
> ```java
> return Application.GetApplication().createRobot();
> ```
>
> The Application class is used to instantiate a Robot.
>
> # Suggested Public API Replacement
>
> `javafx.application.Application`:
>
> https://github.com/brcolow/openjfx/blob/master/modules/
> javafx.graphics/src/main/java/javafx/application/Application.java#L527
>
>  com.sun.glass.ui.Pixels
>
> # TestFX Usage
>
> ```java
> @Override
> public Image getCaptureRegion(Rectangle2D region) {
> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> {
> Pixels glassPixels = useRobot().getScreenCapture(
> (int) region.getMinX(), (int) region.getMinY(),
> (int) region.getWidth(), (int) region.getHeight()
> );
> return convertFromGlassPixels(glassPixels);
> });
> }
>
> private Image convertFromGlassPixels(Pixels glassPixels) {
> int width = glassPixels.getWidth();
> int height = glassPixels.getHeight();
> WritableImage image = new WritableImage(width, height);
>
> int bytesPerComponent = glassPixels.getBytesPerComponent();
> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) {
> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels();
> writeIntBufferToImage(intBuffer, image);
> }
>
>