Marc Vertes on XLab for macro recording

["Dan Kaminsky" <effugas best com>]

I recently emailed Marc Vertes regarding Xlab as a macro tool for GNOME.  He
noted, much as people said in here, that there is much dependance upon
window size in Xlab.  I'm pasting his email to me here, but note this:  A
macro is *still* effective on a local basis, but as Marc says, it'd probably
be better for some kind of app level(or maybe GTK+ level, for 100% GTK
apps!) scripting functionality.

Note, I think Xlab is already sufficiently stable(pending testing by
gnome-gui) for us to suggest *in the style sheet* that help systems be
suggested with 3rd level(recommended) compliancy that they include
screenplays for tutorial purposes.  I see no reason why coders wouldn't like
this.

=======

Dan Kaminsky wrote:
>
> There's alot of interest in xlab right now as a *macro* tool, but people
are
> wondering if they should suggest a system in the style guide that is over
a
> year away in functionality.  What we're worrying about is stuff like
window
> size--how tolerant will xlab be of window sizing issues, and how tolerant
is
> it right now?  We don't want to suggest something if it's not really
doable.
>
I have to enter in some design considerations. The way xlab is dealing
with window geometry:
1. the Window size in XCreateWindow request is used (among other
parameters) to match windows identificators at the beginning of replay.
This is necessary to post events to corrects windows, since the server
is allocating those identificators dynamically. I found out with several
toolkits (not tested with gnome yet), that this size is always the same,
even if the window size appears different (resizing for user preferences
is done in another request). It means that an application replaying with
a different size than at recording will still be "recognized" by xlab
(i.e. correct correspondance of windows identificators). This has to be
validated with gnome but I'm quite optimistic.

2. Each user action (key press/release, button press/release, cursor
motion) are generated with coordinates relative to the window position
(window as it is refered in the X protocol: a window for the user is in
fact a collection of windows a X level), not the absolute coordinates.
It means that replay will be successful no matter the position of the
window on the screen (Example: window is a button inside a frame which
has been resized for user preference), if relative coord. are still
falling inside the window (must not be too small). Now, there are (of
course) some situations where the replay will behave differently: i.e
selection of text in a resized text widget (or where font or font sized
is changed) will probably return a different content than at
recording...

I think also that xlab is quite tolerant to window look and feel, at
least for simple widgets. i.e replay of a button press should work even
if the text content (internationalization) or pixmap (look & feel) is
different from the one at recording.

In conclusion: xlab is tolerant to a number of context changes between
recording and replay, but not to anything (which makes it in fact not
tolerant). In the case of window sizing, it may or may not affect the
replay (depends on the widget).

Xlab should work with great accuracy if the context (say Xdefaults) at
replay is identical to the one at recording. Now, the ways a user can
customize an application (size, font, text content, window visibility
and widget look & feel) make potentially too many differences from the
original context, to ensure a 100% exact replay. Note that those
limitations don't come from xlab itself, but from the X protocol, which
works at low level (no widget or user preferences concept).

For me, the solution to overcome this problem is to be able to script at
widget level (instead of X protocol level): each and every widget item
having a method to be activated from/recorded into a script, with
parameters according to the widget semantic (the only way to be
independant from user setup). This has to be implemented of course in
the toolkit.
A good example of this approach is the tkreplay extension from Jan
Newmarch. It is a motif library extension which provides an entry point
in the process to record or activate Motif widget actions (ie.
foo.menu.button press) from an external process with the "send" command
as in tcl/tk (tkreplay package should be available on a tcl/tk ftp
site).