From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5395 invoked by alias); 25 Sep 2007 18:33:27 -0000 Received: (qmail 5268 invoked by uid 22791); 25 Sep 2007 18:33:25 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 25 Sep 2007 18:33:19 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l8PIXHEA026004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 14:33:17 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l8PIXHR7012278; Tue, 25 Sep 2007 14:33:17 -0400 Received: from [192.168.1.3] (vpn-14-247.rdu.redhat.com [10.11.14.247]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l8PIXGnn016426; Tue, 25 Sep 2007 14:33:16 -0400 Message-ID: <46F95489.3080101@redhat.com> Date: Tue, 25 Sep 2007 18:33:00 -0000 From: Lillian Angel User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Herron CC: =?UTF-8?B?U3RldmUgTWNLYXnimIQ=?= , mauve-discuss@sources.redhat.com Subject: Re: Tweaking default java.awt.Robot settings References: <4f2ee4520709241331o1a77379cudffb314dc1622914@mail.gmail.com> <46F8238C.8020606@sun.com> <4f2ee4520709241422n5ca2cf60g8d37fb76a27d4067@mail.gmail.com> <46F82F8D.6040404@sun.com> In-Reply-To: <46F82F8D.6040404@sun.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact mauve-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00029.txt.bz2 David Herron wrote: > [resending because the mailing list thingy told me I had to use only > plain text messages...] > > Hmmm.. here's the meat of the test > > public void runTest(int code, char chr) > { > KeyEvent e = new KeyEvent(f, KeyEvent.KEY_PRESSED, 0, 0, code, chr, > KeyEvent.KEY_LOCATION_STANDARD); > f.dispatchEvent(e); > f.setSize(200,200); > f.show(); > r.mouseMove(60, 60); > > r.keyPress(code); > r.keyRelease(code); > h.check(key, (int) chr); > } > > I don't understand this. If you're going to create a Java event why > use Robot, or vice versa...? The test was done this way to determine if the right key was pressed. See the inner class (myFrame) which has 1 function (keyDown) which sets a variable (key) to the key that was pressed. While it might be incorrect, I am unsure how else we can determine that the correct key was pressed without dispatching an event. Lillian > > It appears h.check is in gnu.testlet.TestHarness and that it simply > does an immediate check with no waiting. The dispatchEvent call is > going to cause the listener to fire regardless of what's happening > using Robot. > > This looks like an incorrect test, and what I'd recommend is:- > > a) ditch the two lines saying KeyEvent / dispatchEvent ... they are > completely subverting the intent of the test > > b) insert some code so the runTest method waits for the listener to be > triggered. Such as a wait and notify type of semaphor. > > c) I don't know how the test guarantees runTest executes on the event > dispatch thread. Is the EDT as important to classpath as it is to > Sun's Swing? > > - David Herron > > > Steve McKay☄ wrote: >> So would you recommend I ignore the test, delete it, add a comment, ...? >> >> --steve >> >> On 9/24/07, David Herron 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 >>> >>> >>> >> >> >> >