I'm tying to implement #10732
With my current implementation (see attached diff), checking Playback > Stop after current track
is equivalent to enabling Setting > Playlist > Play and stop
.
When quitting VLC, the current state of this boolean is persisted (I checked with grep "play-and-stop" ~/.config/vlc/vlcrc
; this happens when VLC is shutdown, not when the boolean changes) which, I believe, is not the behavior we want for #10732.
If I start VLC with the --play-and-stop
argument, the behavior is also similar to enabling Setting > Playlist > Play and stop
, but this option is not persisted.
I don't understand why, and I don't know how to imitate this behavior from the GUI.
Let's assume the previous problem is solved.
To be user-friendly, I believe that this Stop after current track feature should disable itself when the player is stopped (by the user, or by the feature itself, or for any reason actually).
I don't think this is the same use-cases as for --play-and-stop
.
For the few I understand, it doesn't seems possible:
- to have this behaviour AND
- to reuse the existing
--play-and-stop
implementation AND - to keep the current
--play-and-stop
behavior (which is "always ON")
I need a wise advice here.
We need a boolean variable to remember if the user asked to stop after the current track.
This variable is global to the playlist: it is not a property of each item in the playlist like it is in Amarok/Clementine (at least for now, global is enough).
For now, I'm using a play-and-stop
config key, but I'm not convinced that this is the best way to do it.
I focused on the Qt interface. Do I need to implement it in other GUIs?
I added an entry in the Playback context menu. This is enough for testing and I'll worry about UI when the rest is done.
The UI needs to be able to read & write the state.
Also, we need to bind actions to some events:
- when the currently played item finishes: stop
- when the player is stopped (manually or not): put the state to
false
When the player starts, the state should be false
.
This is not the case for now, because the state is persisted in the config.
Should I implement the state differently, or explicitly set it to false
on startup?