On Wednesday, September 12, 2012 10:57:35 PM UTC-5, Edward K. Ream wrote:
test.leo contains the node, "Prototype of screencast script". It took
many hours of happy experimentation to get the script to work, but the
results are worth all the futzing.
Rev 5434 packages this into the new screencast plugin. Yesterdays work,
in screencast.py and the node "@command screencast @key=Alt-9" in test.leo
taught me several things. In the notes below, m is an instance of
ScreenCastController. m stands for "movie" :-)
1. It's probably best to not to open a new Leo window for screencasts.
This avoid problems with w.repaint occurring in a another repaint
operation, thereby freezing Leo. This is not a major constraint: we
typically will want to have screencasts operate on the local .leo file.
2. I spent a lot of time trying to adjust the delay between "transitions".
The arguments to m.wait specify the range of waiting allowed. The plugin
multiplies these nominal factors by a **speed factor**, initially 1.0.
m.set_speed sets this factor. To double the presentation speed, set the
factor to 0.5.
The m.log call writes a message to the log pane, with calls to m.wait(1)
before and after inserting the text. Both waits are important. The
"opening" wait allows the user to see the effect of the previous operation;
the "closing" wait allows the user to read the new comment in the log pane
before the next operation happens.
3. The futzing with speed and waits convinces me that specifying waits "by
hand" isn't good enough. Pre-specified waits will be useful only for an
**unattended mode** that just plays the screencast from start to finish.
But for most presentations we want the presenter to switch from one
**scene** of the movie to the next by hitting the RightArrow key. The
LeftArrow key will go back to the previous scene. Thus, in **attended
mode**, most calls to m.wait will have no effect. (An exception will be
the calls to m.wait in the code the simulates a person typing in headline
or body text. Thus calls should always have effect, so we will have a
"force" arg to m.wait.)
It will be relatively straightforward to do the first draft of attended
mode. At the programming level, it will work like any minibuffer command
that prompts for user input. That is, the plugin will create a so-called
state handler for the slideshow.
At the design level, the main idea is to treat every node under the main
@screencast node as a scene. This natural division allows the screencast
to organize the material using all of Leo's organizational capabilities.
The state handler will, when seeing the RightArrow key, "play" the next
scene merely by moving to the next node and then executing the script in
it's body text. This script could contain *any* Leo script, but most often
it will call ScreenCastController methods. Moving to the previous scene
can be done by Leo's undo command, automatically managed by the
ScreenCastController. This will be a bit tricky, but not hugely so.
4. Putting comments in the log pane is ok for a prototype, but it's pretty
lame. Instead, I'd like to use some kind of popup that can be associated
with individual items on the screen and located with precision relative to
those items. The popup should be able to contain both text and graphics.
Does anyone have a suggestion for what Qt widget to use?
Your comments please, Amigos.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/leo-editor/-/U5KpYjWzb6MJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
