pal@calmasd.GE.COM (Peter Lawrence) (09/17/88)
This is an X technical question in which I expect a lot of people to have an interest in the outcome. I would like to take XNextEvent and recode it to have normal, record, and playback modes. In normal mode it executes as currently coded. In record mode every event is written to a file before returning. In playback mode events are read from a file. The uses of this feature would include automating the testing of X and X toolkit based applications, and an X toolkit test suite, and in being able to verify bugs assuming the person who reports the bug can record it and it can then be playbacked at a later time hopefully even by running the applicatin on a different machine. The question then is is this technically feasible. A lot of questions come to mind especially with respect to the display and window identifiers in the XEvent structure, and in the area of synchronization of client, server, and window manager communications. How can the window ids in events at record time be coordinated with windows created at playback time. Will some mapping be required. Do window create and destroy actions have to be in the record to be coordinated with real creates at playback time. During playback a lot of real events will come from the server, for example window exposures, which should really be handled, so should these types of events not be recorded, should the recording only contain user generated input like mouse and keyboard events. What types of XLib actions are there that require synchronous replies and for these is it appropriate to use the real event comming back and ignore or not save anything at record time for it. If this had be implemented in XtMainLoop rather than in XNextEvent that would be acceptable to me but obviously not for all the writers and users that dont use "the" X Toolkit. XLib seems to be the right place for this but any comment from toolkit implementors will also be appreciated since putting it in the toolkit will be easier than in XLib if we "have to do it ourselves" and it will only have to be done once (per the one toolkit that I use) rather than for each machine's XLib (do they differ from machine to machine?). This seems to be a meaty question as I have only listed some of the issues that come to mind. Some analysis and comment from the experts will be appreciated. -- pal@calmasd.GE.COM or ...!sdcsvax!calmasd!pal
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (09/27/88)
Date: 17 Sep 88 03:21:47 GMT
From: sdcc6!calmasd!pal@ucsd.edu (Peter Lawrence)
I would like to take XNextEvent and recode it to have normal, record, and
playback modes. In normal mode it executes as currently coded. In record mode
every event is written to a file before returning. In playback mode events are
read from a file.
One result of the X testing consortium work is a protocol extension to record
and playback input events, requiring no modification to clients. A version
of this extension will be available in R3 (although not fully implemented for
all servers).