Hello,
I think that we should extend our Robot implementation, but implement
this with care.
The primary goal of the Robot class is to write the automation tests,
and need of creation of extensions for execution of the elementary
actions leads me to thought that this class can be expanded.
I gu
Yeah, that looks good to me too.
--
best regards,
Anthony
On 8/29/2014 4:52 PM, Dmitriy Ermashov wrote:
Or it could be a Toolkit.nativeEventQueueSync. It would allow us to call
the method in a static way.
Many functional tests have a call like
((SunToolkit) Toolkit.getDefaultToolkit()).realSyn
Or it could be a Toolkit.nativeEventQueueSync. It would allow us to call
the method in a static way.
Many functional tests have a call like
((SunToolkit) Toolkit.getDefaultToolkit()).realSync()
They call realSync without instantiating a robot.
It would be great just replace it with
Toolkit.getD
Yes, that sounds good to me. We need to consider whether this should be
Toolkit or Robot class though, and settle on the name of the new method.
For example, if we go with Robot, then it could be
Robot.waitForNativeIdle() or alike.
--
best regards,
Anthony
On 8/29/2014 4:24 PM, Dmitriy Ermash
Hi Anthony,
Ok, let's summarize:
We leave all functionality in ExtendedRobot except of realSync() call,
which in turn we move to a new method in java.awt.Toolkit.
I believe it could be a reasonable compromise.
Is it ok?
Thanks,
Dima
On 08/28/2014 10:03 PM, Anthony Petrov wrote:
Hi Dmitriy,
Hi Dmitriy,
On 8/28/2014 1:14 PM, Dmitriy Ermashov wrote:
On 08/28/2014 12:09 PM, Anthony Petrov wrote:
On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
At first, let me focus on fact that the actual motivation of moving
functionality to java.awt.Ro
Hi Anthony,
On 08/28/2014 12:09 PM, Anthony Petrov wrote:
Hi Dmitriy, Yuri,
On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
At first, let me focus on fact that the actual motivation of moving
functionality to java.awt.Robot is the Jigsaw project. W
Hi Dmitriy, Yuri,
On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
At first, let me focus on fact that the actual motivation of moving
functionality to java.awt.Robot is the Jigsaw project. We (SQE) will be
unable to use internal java API after the pr
On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
Hi Anthony,
Thanks for your review.
At first, let me focus on fact that the actual motivation of moving
functionality to java.awt.Robot is the Jigsaw project. We (SQE) will be
unable to use internal java API after the project will be finished
(Ext
Hi Anthony,
Thanks for your review.
At first, let me focus on fact that the actual motivation of moving
functionality to java.awt.Robot is the Jigsaw project. We (SQE) will be
unable to use internal java API after the project will be finished
(ExtendedRobot just will not compile, for example)
Hi Dmitriy,
While I realize that all the new methods are useful when writing JDK
regression tests, do you have any evidence that would suggest that these
same methods could be useful to and/or have been requested by external
developers? All of them look like convenient APIs and I'm not entirel
Hi awt team!
A few months ago we have consolidated methods required by functional and
regression tests in ExtendedRobot class. After a period of extensive
testing, it's time to migrate them to java.awt.Robot.
Please review the changeset:
http://cr.openjdk.java.net/~dermashov/8039749/webrev.00
12 matches
Mail list logo
