david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (02/14/90)
Why? For regression testing, but also for "batch" processing (oh no!), for defining macros, for feeding "commands" into a user interface by a text selection... Ideally, such a mechanism would work sorta like the "programming by example" research done at Xerox about a decade ago (see Programming by Example, Daniel C. Halbert, Xerox Office Systems Division for a 1984 description. He wrote other internal memos as far back as 1980). Or Juno. I.e., the user does something, and a file "magically" devlops which mimics the user's actions. This file is a script which can then be read in by that application. The syntax should support arguments to be really useful. My guess is this could be done with a hacked XtMainLoop. Starting and stopping the collection of events from the user, as well as the parameterization bells-and-whistles, would be handled therein. Ideas, anyone???
asente@decwrl.dec.com (Paul Asente) (02/14/90)
In article <7064@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes: >Why? For regression testing, but also for "batch" processing >(oh no!), for defining macros, for feeding "commands" into >a user interface by a text selection... Look at XtSetActionHook and XtCallActionProc in the R4 Intrinsics. This captures the user's actions at the action procedure layer, which is probably what you want to do for many applications. -paul asente asente@decwrl.dec.com decwrl!asente
mjb@visual.UUCP (02/15/90)
In article <7064@jpl-devvax.JPL.NASA.GOV> you write: >Why? For regression testing, but also for "batch" processing >(oh no!), for defining macros, for feeding "commands" into >a user interface by a text selection... > >I.e., the user does something, and a file "magically" devlops which >mimics the user's actions. This file is a script which can then >be read in by that application. A very similar beast was produced by the late, lamented X Test Consortium (no affiliation with the MIT X Consortium). A mechanism known as the Input Synthesis server extension was developed by HP for testing X server implementations, but is generally useful for testing X applications as well. The extension's main calls are XTestMovePointer, XTestPressButton, XTestPressKey, XTestGetInput, and XTestStopInput. A couple of host clients, xrecord and xplayback, create and replay a script of input actions. I'll mail you the spec. All Visual X terminals have this extension, if you're interested in playing with it. Mike Braca Visual Technology mjb@visual.uu.net +1 508 836 4400
hvr@kimba.Sun.COM (Heather Rose) (02/16/90)
In article <7064@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes: > >My guess is this could be done with a hacked XtMainLoop. Starting >and stopping the collection of events from the user, as well as the >parameterization bells-and-whistles, would be handled therein. > >Ideas, anyone??? Journaling or scripting is a very common request from end-users, and a very difficult thing for a server or toolkit to supply--correctly. One could do this in XView by using notify_interpose_event_func() and notify_send_event(), but the problem of synchronization and reproducing certain conditions remains. It could be done for a special case, but it is harder to make it a general piece of functionality. OpenWindows provides a journaling tool which takes advantage of the NeWS side of the server, but this too is not bulletproof. Any kind of tool like this is subject to race conditions in the operating system, network, server, toolkit, application or in the case of X11 the protocol. Classic example, you have a tool in position X, Y which pops up a menu, the user selects an item in the menu which does a task. When you replay the same sequence, the tool is now in a different location, the menu hit may or may not occur within the scope of the application, or the time between events is different, so order becomes more difficult, etc... It's much easier to model the calling sequence of action procedures than to duplicate the user's interaction. Anyway, I do not doubt that a single application could do this, but it is a much more difficult problem to provide journaling for the general case...when you have interaction between two processes. To abstract a bit, consider the scripting language for /bin/sh. Most shell scripts will execute one task to completion before starting the next one. If I were to start two builds in the same directory by putting them into the background: % make & % make & The second "make" has the potential to clobber all the work of the first "make". To avoid this, they are processed sequentially. The same principle holds for programs which rely on output from another for their input: % who | sort The "sort" process will not execute until it has received its input from the "who" process. If we changed this a bit to put both who and sort into asynchronous mode with some kind of checkpoint in a file: % who > /tmp/who.out & % sort < /tmp/who.out & We have just introduced another race condition. Will "who" finish in time for the "sort" process? So, in the scripting language for /bin/sh we assume certain conditions: well defined scripting language same behavior interactively as non-interactively scripting language interpretor tasks are synchronous when timing matters tasks are asynchronous when timing does not matter (backgrounding) well defined path for input and output streams (checkpoint with pipes) Anyway, this makes a very small stab at some of the more obvious issues involved with journaling. Heather
john@acorn.co.uk (John Bowler) (03/07/90)
In article <9002150428.AA06493@bird.visual.uu.net> mjb@visual.UUCP writes: > >A very similar beast was produced by the late, lamented X Test >Consortium (no affiliation with the MIT X Consortium). Eh? Has it gone then? Can anyone tell me what happened... John Bowler (jbowler@acorn.co.uk)