From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21646 invoked by alias); 24 Sep 2007 20:31:59 -0000 Received: (qmail 21637 invoked by uid 22791); 24 Sep 2007 20:31:59 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Sep 2007 20:31:55 +0000 Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id l8OKVlSX009930 for ; Mon, 24 Sep 2007 21:31:47 +0100 Received: from wx-out-0506.google.com (wxdi28.prod.google.com [10.70.135.28]) by zps75.corp.google.com with ESMTP id l8OKVQNO007841 for ; Mon, 24 Sep 2007 13:31:39 -0700 Received: by wx-out-0506.google.com with SMTP id i28so1089437wxd for ; Mon, 24 Sep 2007 13:31:38 -0700 (PDT) Received: by 10.78.193.5 with SMTP id q5mr3900955huf.1190665898130; Mon, 24 Sep 2007 13:31:38 -0700 (PDT) Received: by 10.70.39.13 with HTTP; Mon, 24 Sep 2007 13:31:38 -0700 (PDT) Message-ID: <4f2ee4520709241331o1a77379cudffb314dc1622914@mail.gmail.com> Date: Mon, 24 Sep 2007 20:31:00 -0000 From: "=?UTF-8?Q?Steve_McKay=E2=98=84?=" To: mauve-discuss@sources.redhat.com Subject: Tweaking default java.awt.Robot settings MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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/msg00022.txt.bz2 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? -- Steve McKay