From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4286 invoked by alias); 25 Sep 2007 19:58:32 -0000 Received: (qmail 4278 invoked by uid 22791); 25 Sep 2007 19:58:32 -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 19:58:27 +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 l8PJwEg3022987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 15:58:24 -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 l8PJwDNN018745; Tue, 25 Sep 2007 15:58:13 -0400 Received: from tortoise.toronto.redhat.com (tortoise.toronto.redhat.com [172.16.14.92]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l8PJwCOK027897; Tue, 25 Sep 2007 15:58:13 -0400 Message-ID: <46F96854.6080706@redhat.com> Date: Tue, 25 Sep 2007 19:58:00 -0000 From: Thomas Fitzsimmons User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: =?UTF-8?B?U3RldmUgTWNLYXnimIQ=?= CC: David Herron , mauve-discuss@sources.redhat.com Subject: Re: Tweaking default java.awt.Robot settings References: <4f2ee4520709241331o1a77379cudffb314dc1622914@mail.gmail.com> <46F8238C.8020606@sun.com> <46F95466.7070700@redhat.com> <4f2ee4520709251156yde57b65tbb97032939ac75e6@mail.gmail.com> In-Reply-To: <4f2ee4520709251156yde57b65tbb97032939ac75e6@mail.gmail.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/msg00037.txt.bz2 Steve McKay☄ wrote: > Hi Thomas, > >> If Robot can't be counted on to do something within some time >> delay, is it also useless in non-test applications? > > David's suggestion to use multi-threaded paradigms for dealing with > the issue seems pretty good to me. Yes, I shouldn't have said useless.. maybe "hard to use" :-) In Mauve we traded timing-independent reproducibility for test case simplicity. I did try writing synchronized Robot-using tests but it was a) difficult, and b) invasive, in that it required overriding and modifying the behaviour of methods that were being tested. > For example, we can block until a > window is ready to process events with code like this (only half baked > at this time): Even after you've ensured that the frame has responded, subsequent checks will still need to be synchronized, since Robot calls are not synchronous. Or is this the specific problem that was causing test failures for you before -- that frames take a long time to be ready to receive events on other runtimes (e.g. Wine)? If that's the main problem then maybe a hybrid approach of synchronizing frame readiness, then assuming small delays for Robot method calls, is a better approach. Otherwise the proposal is to rewrite every Robot-using test to be perfectly synchronous (fine by me, but a big job). Tom