Add live mode to control features (#155 issue)

FrancescoCeruti / linux-show-player

Linux Show Player - Cue player designed for stage productions

https://linux-show-player.org

GNU General Public License v3.0

205 stars 49 forks source link

Add live mode to control features (#155 issue) #157

Open Gajenthran opened 5 years ago

Gajenthran commented 5 years ago

Here is a solution for the issue #155 . I decided to catch events and disconnect them if the live mode is active (all events are disconnect by default but we can configure that). But I had two main problems :

With this method, I can't realize the mode proposed by @fralix because when I disconnect an event, it will concern all cues. So the solution will be to modify the behaviours of cues instead of events. I'm trying to work on that, but before modifying many things on the code, I would like to hear solution of other people.
I can't add/modify configuration file to put by default live mode in false (which will deactivate the live mode at the beginning). So I decided to give the same behaviour as selection mode. If you don't understand what I mean, you can check the file layout.py (line 140).

FrancescoCeruti commented 5 years ago

:thinking: I think that what we should aim for is a session property (which is saved in the show-file, not globally, see core/sesson.py):

the entry in the configuration might be annoying if you switch between different session and those are opened with the last show option
other components (like the layout) can observe if the property change to, eventually, change something internally (e.g. enable/disable some GUI piece or hide/show them), similarly to yours _set_live_mode
in some case it might be enough to check, for example, if session.mode == SessionMode.LiveMode, and a plugin or whatever can behave differently

This can be more verbose, but you have more fine control on what to do when changing mode.

fnetX commented 5 years ago

Well, I don't really think that this should be a per session setting, but an easy-to-change button in the interface. If you closed a session in live mode, and open it right before an event, you'd already be in live mode with the chance to accidently trigger something if it is as easy as proposed for the live mode. Thus, I recommend opening the file in the default (editing) mode and having two handy buttons to go into Preview or Live (if realizing my proposition).

Refering to the QLC behaviour again: Live mode is just one click ago :-)

Gajenthran commented 5 years ago

Extremely sorry for my absence ! If I understand what @FrancescoCeruti meant, I think we will still have an easy-to change button in the interface as you said @fralix but we will save this option (Preview, Live mode) in the session file. By doing this, we don't have to change the mode each time we open a session.

FrancescoCeruti commented 5 years ago

Yes, I've actually reacted to the presence of the liveMode in configuration file, but maybe you don't even use that? Probably fralix is right and we should not save the current mode at all.

Gajenthran commented 5 years ago

I talk with somebody about that, and they told me it was not so disturbing. To switch from one to another, "it's just a simple click". For me, it's not a problem too (but I think my opinion is not important because I'm not a big consumer of this kind of application, so I don't know if I'm the right person to talk about that).

other components (like the layout) can observe if the property change to, eventually, change something internally (e.g. enable/disable some GUI piece or hide/show them), similarly to yours _set_live_mode

Are you saying that the method _set_live_mode is not useful here ? Or it's in the case we add a session property ?

fnetX commented 5 years ago

Well, yeah. I'd say it's not a good idea to save the mode, as I'd expect a workflow with "live modes" as something like "Open > Edit > Preview > Live" or "Open > Live" if I already prepared everything.

Gajenthran commented 5 years ago

I finally clear some useless function and add "preparation mode". For the live-mode, I think we can also add the GUI pieces that we want to disable in the JSON file (at the moment, all the pieces are disabled) For the preparation-mode, the running cues can't be selected (but only the running cues before the preparation-mode are concerned. At the moment, we can't block running cues during the preparation mode, that's why I would like to have your suggestion about that because we should collect all events (Play, Stop, FadeIn...) to lock/unlock cues)