This is the mail archive of the
mailing list for the Mauve project.
Re: Tweaking default java.awt.Robot settings
So would you recommend I ignore the test, delete it, add a comment, ...?
On 9/24/07, David Herron <David.Herron@sun.com> wrote:
> Steve McKayâ wrote:
> > Hi All,
> > I've noticed that at least some of the tests using java.awt.Robot are
> > non-deterministic due to lags is the underlying window system. The
> > java.awt.Component.keyPressTest, for example, fails some of the time
> > (on linux, windows, linux+wine, ...). It looks like enabling
> > autoWaitForIdle (waits for the awt EventQueue to be empty before
> > adding new events to the queue), and setting autoDelay (pauses for an
> > arbitrary period of time) to some magic number of millis well above
> > zero (I use 100) significantly reduces failures. Would anyone object
> > to configuring the Robot with settings like this by default? If no,
> > should the config mechanism be updated to allow tweaking these
> > settings?
> I don't know what the classpath implementation of Robot looks like, but
> I do know what Sun's Linux/Unix implementation looks like (having
> written the original version).
> Generally Robot has to request the OS or X11 to synthesize the event.
> On Windows there's a direct API call, while on Unix/Linux there is a
> child process which ends up calling XTEST extension methods. In both
> cases it means there is a nondeterministic delay due to the current
> process scheduling characteristics of the given system. In other words
> it depends on an external entity, who Robot cannot coerce into
> performing the request within a bounded set of time.
> I think that means depending on Robot doing it's thing within a given
> period of time is an invalid test.
> Robot does not add events to EventQueue but it requests the OS to
> synthesize an OS-level event.
> - David Herron
Steve McKay <firstname.lastname@example.org>