[MPlayer-dev-eng] The GUI and the configuration files

[Ivan Kalvachev]

On 4/25/11, Ingo Brückl <ib at wupperonline.de> wrote:
> I'm currently working on the config file part of the GUI (gui.conf) which
> I'm
> extremely unhappy with.
>
> To the ordinary user it must look like utter chaos which options will
> finally
> be used and/or set. My first attempt to clear things up led to r33311.
>
> It'd be ok if there were a GUI config file for GUI-only/GUI-specific
> options,
> but unfortunately it contains MPlayer options as well and - to make things
> even worse - two types of these options. Some options have different syntax
> and use own variables and must be translated into MPlayer options, some use
> the very same MPlayer global variables directly.
>
> I currently can't think of a reason why MPlayer options have to be
> overridden
> for a GUI to run, but I reckon that this is only because the GUI
> could/should/wanted not to write to MPlayer's config file which certainly is
> ok.
>
> Leaving the problem of the content of gui.conf aside, the general
> relationship of config files however is clear. First coded defaults are
> used,
> then the system config, then the user config, then (in case of GUI) the GUI
> config, and finally the command line options.
>
> Although the GUI complies with that, it stores all its settings when ending
> which will result in command line options (if they happen to be some of the
> GUI options of any type) to become fixed settings for the next run without
> command line options. (Same if a first type GUI option had a different
> default than the corresponding MPlayer option.) And that is weird and must
> not happen.
>
> So what I intend to do is three different things:
>
> 1. (now) Don't store settings automatically. Only store them (explicitly) in
>    the GUI's configuration dialog.

Some of the options, e.g. volume, equalizer are not limited to the
properties dialog.
Saving changes when the corresponding dialog is closed makes a lot of
sense, e.g. changes won't be lost if gmplayer crashes or is forcibly
killed.

One much harder related problem is if you want to change option  with
editing gui.conf directly, but there is still gmplayer running. For
now, saving only after dialog change would indeed remedy most cases.

However the "OK" "Cancel" and "Save"/"Apply" scheme may be kind of
tricky and confusing.
E.g. in windows "OK" would first apply the changes then exit the dialog.
Having "OK" keep the changes until next restart would be quite unusual
behavior (for me). So I'd recommend to keep it simple and just have
"OK" that saves the changes and "Cancel" that ignores them.

> 2. (later) Change gui.conf to use nothing but the same variables as MPlayer.
>    Add a translation from legacy options to new ones so that the user isn't
>    affected (too much).

It would be good idea if all gui specific options do start with gui_ prefix.


> 3. (later) Add all GUI options to its configuration dialog. (And somehow
> show
>    which MPlayer settings will (currently, from MPlayer's global variables)
>    be used if a GUI options remains unset.)

I'm not sure what this means. I don't care if given option global or
gui specific. Users should care even less. Do you mean a way to
indicate options that are not at their default value?

Generally, having a way to reset all gui.conf options to the
"defaults" would be highly appreciated.
In the past we had a number of problems solved by asking users to `rm gui.conf`,


> Is this a reasonable plan? Do I miss something or are there any proposals?
>
> Ingo