Alexandre (Shura) Iline
alexandre.iline at oracle.com
Wed Feb 22 16:03:46 PST 2012
On 2/23/12 12:08 AM, Anthony Petrov wrote:
> Hi Richard,
> On 2/22/2012 8:12 PM, Richard Bair wrote:
>> I have a few issues logged against FXRobot (particularly, to clean up
>> the TODOs) and so I took a few moments this morning to look it over.
>> The code is in javafx-ui-common in the com.sun.javafx.robot package.
>> First question, at present there is an FXRobot base class and a
>> factory and a BasicFXRobot implementation. Is this structure still
>> relevant? I have my hunch that this is carry over from back in the 1.0
>> days when we had a separate JavaFX Mobile implementation, whereas now
>> we are consolidated on a single implementation and it should no longer
>> be needed to have this separation. I prototyped merging the
>> BasicFXRobot implementation into the FXRobot class, making FXRobot
>> final, and removing the factory. The runtime builds fine.
> Are we sure we'll never ever want to have an implementation of the
> FXRobot class that would generate real, native input events? (i.e. be
> based on Glass' Robot implementation?)
I suggest that in Jemmy we just use glass robot directly.
>> Shura, do you use FXRobot at all?
>> Does anybody really use FXRobot right now? I don't think any of the
>> unit tests use it (and in fact, there have been utilities added to the
>> unit tests to generate fake key events and so forth, so I'm pretty
>> sure FXRobot is not in use here).
>> There are also some odd dependencies -- accessors -- in KeyEvent for
>> example such that KeyEvent calls into FXRobotHelper with a static
>> initializer and so forth. What is that all about?
>> My hunch is that either (a) FXRobot isn't really used and therefore we
>> can just chuck it or, (b) SQE is using it, but it could be simplified
>> and the funny back references from KeyEvent etc can probably be
>> removed (although since I don't know why they are there in the first
>> place I can easily be off base here).
>> Shura, others, can you guys help shed some light here?
> ...but if SQE agrees (and AFAIK they currently use AWT Robot only), then
> I'd say that removing it all together seems like the best solution for
> now. We can always add it back if we need to.
> best regards,
More information about the openjfx-dev