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

[Ingo Brückl]

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.

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

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

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

Ingo