More XLab stuff from Marc Vertes

["Dan \"Effugas\" Kaminsky" <effugas best com>]

Even more email to post...Xlab looks nice for what we need.

Dan Kaminsky wrote:
>
> Your description, and your work on Xlab has been excellent.  Here are my
> suggestions, as a comaintainer of the GNOME Style Guide project, for what
> *we* would like to see Xlab possess.  PLEASE DO NOT consider this
> demands...this is just what we want to be handing over to gnome-dev as
> "look, here's something to join the cvs as a core component we think is
> absolutely awesome and is something nothing else has".
>
OK, great. I'm impatient of seeing great and imaginative use of Xlab.
What those 'gnome-dev' guys think about it?

> 1)  Some kind of backwards/forwards/breakpoints allowable but skippable
> protocol.

Breakpoints: yes (easy to do, may be next release, as I planned to
implement it anyway), forwards: may be ok (matter of 'skipping' some
events, but may be some context problems), backwards: I don't see how to
'reverse' actions.

> 2)  Some kind of functionality for "help text" to be integrated into the
> help stream at a later date.  In other words, a way for an application to,
> in the same datastream as the original x set, create a movable window that
> draws lines from itself to an arbitrary portion of the screenplay with
given
> text inside.  Also, (animatable?) text should be overlayable over the
> interface.

This can be easily (and already) done by recording text entry (keyboard)
into a simplistic text widget (example: a tcl/tk script consisting of
only a text widget), and play it in parallel of the help application
demonstrator (xlab can handle several clients). Of course, you are not
obliged to actually record all the text, you can edit the script and
simulate key entries as if they are typed in real time (without
mistakes). No need to modify xlab for that one, just a proper use of it.

> 3)  *MAYBE* some kind of way to integrate audio recording and playback.
> Consider this optional to the extreme.

Again, you don't need to modify xlab for that (except for the ability to
start a unix command in the sequence of recorded events, feature that I
will add in the next release), you could use it to play pre-recorded
files (with existing players: i.e.
"cat speech.au >/dev/audio" ) at the right time, because the start of
speech will be synchronized with the events sequence.

In Dreamland, I would integrate speech recognition software with xlab (I
guess such packages already exists in Unix/Linux at least in
experimental stage) to pilot ANY application from voice :-) (Ok, I start
a "future of Xlab" page on my site, and put this one on top)

> 4)  Remote collaboration.  What CCF does is allow any number of users to
> "share" a given application, with live realtime speech communication.
> CCFSound is a stand alone voice app, you don't need to worry about that,
but
> some kind of networking functionality to allow one X window to exist on
> another user's screen and for all users to be able to contribute and/or
> whiteboard on top of a certain window would be *excellent* functionality.
> Perhaps a bzipped stream inbetween parties?  I don't know, I'm not the
> coder.  I just think multiperson word/GIMP would be ubercool.
>

I think you're right. xlab architecture could be easily expanded to
allow multi-conferencing for any X application, no problem also to take
the opportunity of compressing the X protocol stream between the
different xlab clients/servers. (another entry for the
"Not-so-distant-future of Xlab" page :-)

> I'm the creator of the screenplays-for-gnome concept, and I have to say,
> your application showed up damn near like manna from heaven.  You're
giving
> GNOME it's first piece of Killer Functionality, and thank you so much for
> getting the "there's no way this is going to be implementable" people off
my
> back :-D
>
You're welcome. It's a great pleasure to receive such inspired ideas to
make evolve this project in very interesting directions which I didn't
foresee at first.

> Just thought of one thing--you'd no longer be directly controlling a given
> application, but rather recording its inputs AND outputs.  Is this a
> problem?

No, it's only a matter of filtering correctly the X stream...


Regards

Marc