Feature request: black/white frame

[odyn]

This one could perhaps be made just with a shortcut. Sometimes during presentation you want the audience to stop looking at the presentation, so you want to 'turn it off' temporarily (without turning off a projector or the screen). Of course I could have a black and white frames at the end and skip to them manually (from the list), but a shortcut could be much more convenient for practical work.

[loookin]

It should be nice, that the shortcut will be "." (dot-key) as MS PowerPoint and LO Impress use it in this way. Also many hardware presenters are sending this shortcut with the "blank" key.

[rauferd]

I agree with you on the need for an "idle" or "standby" frame.

I would like to add that PowerPoint and Impress implement two keys for this feature ("." and "b") and that at least my presentation remotes send the "b" key exclusively.

Also, in #191 I suggested to jump to a custom frame instead of a black (or white) frame.
I'm not saying that this is badly needed, but it would definetely be much more flexible. Everybody is free to define a blank idle screen, but you could also show the logo of your company, university or NGO.

Maybe it's good idea to have a poll on this feature request before implementing one or the other.

[rauferd]

Any upgrade on this? I am still using Sozi regularly and I am still interested in this feature.

I take it from this site, that the key bindings will be updated with Sozi 15:
http://sozi.baierouge.fr/pages/40-play.html
This would be a great opportunity to introduce this feature, I'd say.

One very simple way to implement this is to use the last frame as the "pause" frame.
Then, only this part of the code had to be changed:

case 35:a.shiftKey?this.jumpToLast():this.moveToLast();break;

I somehow got this to work here, but it's not very elegant, so I'd rather post a pseudo-code example:

case 35:
<check if current frame = last frame>
  <if yes, read the previously-displayed-frame-variable and jump that frame>
  <if no, save currently displayed frame in the previously-displayed-frame-variable and jump to the last frame>
break;

The shift vs. regular click effect could also be applied to the reverse jump.

Everybody could easily change "End" to his favorite key by adding more case statements in front of the above.

[aumouvantsillage]

Any upgrade on this?

Not yet.

I take it from this site, that the key bindings will be updated with Sozi 15:
http://sozi.baierouge.fr/pages/40-play.html

No. Actually, the key bindings have already been changed. The documentation page needs to be updated to reflect how Sozi 15 works.

I see that I did not answer to your previous comment. Currently, my preference would go to a blank screen rather that jumping to a specific frame.

[ejvindh]

A workaround until implemented: When I need a black screen, I simply open a new window or tab in my browser with this page:

http://ejvindh.net/b.html

[robertrosman]

I've implemented a quick and easy way to accomplish this using some css transitions. There might be better ways to do it, but I think this will do the job. A demonstration may be found here. Try pressing the dot key to turn the screen black. Do we need to tweak it further to fit our needs?

[rauferd]

roggan87,

I think the solution is actually quite elegant, since it does not require any frame changes that may break other functionality.

The possibility to continue the presentation while the screen is blank is somewhat unexpected, though. I would certainly want at least the auto-play to stop when switching to the blank screen.
It's as easy as adding this.pause(); behind this.toggleBlankScreen();

On the other hand, it may actually be interesting for some users to continue the presentation with a different frame when returning from the blank screen.

Before deploying this feature, one needs to think about the most appropriate behavior of the "." key:
Pause when switching to the blank?
Auto-resume when switching back?
Disallow some (or all) navigation keys?
How about embedded media (audio, video): Should they stop as well? For background music, I'd say no, for a video definitely yes.

For the time being, I will use your solution as-is. Thank you.

[robertrosman]

@rauferd, thanks for your feedback! I agree with you regarding the autoplay. And as you say, we need to talk through how the rest of it should behave. Glad you find it useful :)