linux-show-player

linux-show-player copied to clipboard

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).

: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.

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 :-)

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.

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.

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 ?

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.

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)