Demos and Tutorials using Journal

[Dave Ciemiewicz]

In article <4931133 at um.cc.umich.edu>, Tim_Buxton at UM.CC.UMICH.EDU writes:
> For anyone who has to do a "demo" of anything on an IRIS, there is 
> now a really great tool for recording a whole demonstration once,
> including all keystrokes and mouse movements at the speed you want, 
> then playing it back any number of times, at selectable faster
> or slower speeds.   It is called the "journal"
> facility and just came out with 3.1g, I believe. "Journalrecord 
> filename.jou" begins the recording, and "journalend" stops it. 
> "Journalplay filename.jou" begins playback.  Or, "journalchest" can
> show a panel with record, stop, and playback buttons to do all
> of the preceeding.  If you aren't using this feature yet, I 
> recommend trying it.  We plan to use it to distribute some
> tutorials along with a new facetizer for BRL-CAD MGED files
> called FRED.
>  
>   Now to mention a few problems I have found:
>  
>     1.  There are problems going from one machine (4D/70) to the
>     other (4D/50).  The commands seem to get given before the machine
>     is ready for them.  There is a speed adjustment - will this help,
>     or is there a difference in the keyboard signals between machines?
>     I notice that keyboard entry is stored not by ASCII code, but
>     by keyboard code, twice per keystroke.  If a speed adjustment
>     does not slow it down enough, would it make sense to multiply
>     all the numbers in the first field, which seems to be an 
>     "event time" field, by some factor to slow it down more?

The journalling mechanism is based on the NeWS journalling capabilities
with some convenient scripts -- journalrecord, journalend, and journalplay --
used as wrappers for driving a remote machine or terminal, or from within
a shell script.  The journalchest is also a wrapper for simple driving
of the recording, stopping, and playback mechanisms.

Mouse and keyboard events are recorded in a journal file simplay as an event
and a timestamp for when the event occured.  Upon playback, events are played
back with the same timing as they were recorded.  Since there is variance
in the amount of time it takes for the system to react to events such as
starting applications, it is very possible for the playback mechanism to
get ahead of the system.  We humans can adjust for these variations but
the playback mechanism only has a gross playback speed adjustment.  Using
the playback speed adjustment (journalplay -p <speed-multiplier>) should
help to some degree.  The keyboard does not come into play as all of the
mouse and keyboard events are simulated in 4Sight and never actually use
the keyboard or mouse.

In my experience with the journalling, I recommend you do make all of
your mouse actions while recording slow and deliberate.  It is very easy to
go zipping through a menu while recording and end up with the wrong
menu selection during playback.

Also, when starting applications with the mouse wait 5-10 seconds after
you see the window outline before manipulating the window outline to place
the window.  This will allow for variance in the amount of time required
to launch an application on a 4D/70 versus a slower 4D/50.

Because of system speed variations, don't try to use journalling for recording
real-time interactive applications like "flight".  However, it is quite
satisfactory to use journalling for recording non-real-time demos.  I used
it to record a fairly sophisticated "live" demo we did for the Personal Iris
unveiling a year ago.

>  
>     2. Stopping the journal playback can be done by pressing any
>     key or moving the mouse yourself.  You are then totally out
>     of the playback, however; it will not start up again from that
>     point.  For new users watching a tutorial, the ability to stop, 
>     then resume would be invaluable.  For giving presentations to
>     groups (SGI salespersons are you listening?) it would be 
>     very helpful to be able to stop to answer questions or make
>     a point, then continue.  The SGI Hotline person I asked about
>     this concluded after some thorough checking that "Pause" is
>     not supported, although they might try to support it at a 
>     later time.  Has anyone come up with a "Pause" feature on
>     their own?
>  

I cannot comment on implementing Pause, you could try modifying:

	/usr/NeWS/lib/NeWS/journal.ps

if you are up to a challenge.

>  
> I would like to hear about possible solutions to the above
> problems, as well as kinds of demos/tutorials/presentations that 
> are being done by various users that could help all of us respond
> the the perennial question "Could you show me what it can do?"
> Thanks.
>  
>  
> Tim Buxton
> OptiMetrics, Inc.
> Tim_Buxton at um.cc.umich.edu
>  

							--- Dave
--
-------------------------------------------------------------------------------
			Cosmo Ciemo, Silicon Valley Dude

I was traipsing through the fields of my mind when I stepped in something that
smelled rather ripe.
-------------------------------------------------------------------------------