Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sgi!ciemo@bananapc.wpd.sgi.com From: ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) Newsgroups: comp.sys.sgi Subject: Re: Demos and Tutorials using Journal Summary: Some help with the journalling Message-ID: <42154@sgi.sgi.com> Date: 25 Sep 89 20:36:27 GMT References: <4931133@um.cc.umich.edu> Sender: ciemo@bananapc.wpd.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 103 In article <4931133@um.cc.umich.edu>, Tim_Buxton@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) 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@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. -------------------------------------------------------------------------------