Qt/macOS: preferences are confusing
Some preferences have an immediate effect, some have an effect only if you restart the playback (vout one for example) and a lot others have an effect only if you restart VLC (aout ones for example).
I see 3 says to fix this issue:
- Tell users that preferences will be applied when they restart VLC (propose a restart button ?);
- Put more callbacks and try to apply preferences immediately;
- Restart the aout if an audio settings is changed, same for vout and others. Simpler to implement than putting callbacks everywhere. You still need to restart the playback but not the whole program.
Activity
added Component::Interface: Qt Severity::normal Type::bug Version::master git + 1 deleted label
changed milestone to %4.0
assigned to @tguillem and unassigned @MigrationBot
I prefer the 3rd solution:
In the future input manager, I would like to add a way to invalidate audio/video/sout/input/others from the qt preferences.
If a part is invalidated, the input manager will restart it before a new playback is started (We can also ask users if they want to restart immediately).
Replying to [ticket:19879 Thomas Guillem]:
Some preferences have an immediate effect, some have an effect only if you restart the playback (vout one for example) and a lot others have an effect only if you restart VLC (aout ones for example).
I see 3 says to fix this issue:
- Tell users that preferences will be applied when they restart VLC (propose a restart button ?);
There used to be such an option. It derailed as nobody settled what it meant exactly: restart the process, the instance, the input resources or the input. Also in many cases, the same setting can be used in different context, with different scope (especially for the more utilitary plugins).
To implement this properly, we would need to track which configuration items are currently "in use" and how. But that is a whole lot of infrastructure, with questionable cost/benefit.
It also lead to intractable conflicts with input item options and configuration chains. No matter what you restart, if an input item option or the configuration chain overrides a configuration item, it will take precedence, and the configuration will never be applied.
- Put more callbacks and try to apply preferences immediately;
There also was that at some point. It caused interesting bugs with the module bank if the module was not loaded. In the mean time, that problem has been sort of solved for the enumeration callbacks.
However the more difficult problem was that there are most typically no ways to get a hold of the correct object - as most objects are not visible to the interface thread that updates the preferences.
As far as I recall, the very few callbacks that were actually implemented all had races. I expect that it would be even worse now, both as we have more objects and threads, and are more aware of encapsulation and threading issues.
Basically, this is easy to implement as a mechanism, but it suffers the same limitations as the previous option. With such a top-down approach, you cannot really beyond the LibVLC instance parameters. In most cases, a bottom-up system is unavoidable.
- Restart the aout if an audio settings is changed, same for vout and others. Simpler to implement than putting callbacks everywhere. You still need to restart the playback but not the whole program.
Actually the audio output is the least of problems. All or almost all audio output and filter parameters can already be changed live from the playback GUI, the Audio menu, or the filter panel. I don't have even one audio output parameter that would actually need a restart today on top of my head.
In any case, I think this is bad. I feel much better telling the user that s/he needs to restart playback than automatically restarting it blindly. Also this suffers the same fundamental problem as the other two options.
Empirically, the first two approaches have been tried and failed. And the third one seems likely worse.
For previous references: #18701 (closed)
See #1701
Very strange that a topic was revived which I have written before, and which was then closed on me which the argument "worksforme". I remember that growing into an argument between me and Denis-Courmont. But anyway, glad to see the topic is now being taken serious after all.
I would like to add that this ticket is also related to reworking preferences: https://trac.videolan.org/vlc/ticket/18607
(Intuitive user interface: bold preferences if not default setting)
mentioned in issue #6042
marked this issue as related to #6042
marked #27643 (closed) as a duplicate of this issue
marked this issue as related to #27643 (closed)
