Open sellout opened 8 years ago
Some (second) thoughts I’m having about this. Overall, I think it’s very helpful, but there is at least one part that I’m not certain how to deal with – the frame
slot in epresent-presentation
.
I encapsulated it because at the time I was thinking that some presentations might have a single slides frame while others have a slides frame, plus speaker notes, and perhaps even others that have different frame setups – e.g., if there are multiple projectors, and the presenter wants different content on each, in addition to a third with speaker notes.
However … in the multiple-presentation case, I’d like to have a single slides frame and a single speakernotes frame, and then be able to cycle through the live presentations, using the same frames, rather than having a distinct set of frames for each presentation.
So, perhaps a set of frames is independent of the presentation, and there is some (customizable) mapping between presentations and frames.
Thoughts?
I like the encapsulation and the idea of being able to cycle through speaker notes at the same time as having the presentation up.
W.R.T. speaker notes, here is what my ideal would be. Write the speaker notes in sub-headings with some tag the indicates that subheading is not to be displayed in the presentation (e.g., COMMENT). When launching the presentation, add an option to keep the original Org-mode file visible in the existing window, while launching the presentation full screen on another monitor. Then provide for the following control options. (1) In the presentation window, standard epresent keybindings apply, (2) in the "notes" window standard Org-mode bindings apply. This would be really great if it allowed the speaker to make edits and evaluate code blocks on the fly with the presentation automatically updating. I don't know if or how this fits into the encapsulation model you've developed, just sharing my thoughts.
Thanks for all of these great contributions!
This introduces a class
epresent-presentation
that holds anything specific to a particular presentation. It also makes things much more lexically-scoped (although there is still too much that depends onepresent--default-presentation
).This is a first step toward two features:
The one “breaking” change here is that the
epresent-mode-line
variable has changed. It’s now a function (taking anepresent-presentation
instance) that evaluates to a mode-line format.