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

[Ivan Kalvachev]

On 4/26/11, Ingo Brückl <ib at wupperonline.de> wrote:
> Ivan Kalvachev wrote on Mon, 25 Apr 2011 21:09:02 +0300:
>
>> 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.
>
> This would be the same with a save button.
>
>> E.g. in windows "OK" would first apply the changes then exit the dialog.
>
> Isn't that annoying? If you want to check out some options and you then
> realize that they don't do what you expected, you'll end up with a totally
> messed up config.

Yes it is annoying, unfortunately the paradigm is already well established.

if you go ahead with the "Save" button, it would either imply that
other buttons don't save or that other buttons duplicate its
functionality. The users should figure out on their own what is what.
However ...

Buttons "OK" "Exit" "Close" have been used in the meaning of "save and
exit" for decades, so using them for anything else will cause
confusion.
In order to avoid confusion you should give long and descriptive names
to the buttons.
e.g. "Close without save" "Close and save" "Save" "Cancel" "Default".

IMHO
Having "OK" "Test" "Cancel" "Defaults" is most optimal, where:
"OK" is  save and close;
"Test" is close without save;
"Cancel" is revert to the changes before the dialog have been opened
and then close it;
"Default" revert all options to the defaults.

All meaning in the above are well established, except the "Test" one.
It is unusual enough but also the user would know intuitively that it
won't do an permanent damage (aka save the config).


There is something else I should mention.
At the moment there are options that need restart to take effect. At
least the gui itself says so.
It would be good idea to find out which these options are and display
the warning only if the user actually changes them.

This handicap probably is going to cause most problems with the
explicit "Save" button scheme. Some option would appear enabled, while
they are not, and the user won't know which these options are.


>> Generally, having a way to reset all gui.conf options to the
>> "defaults" would be highly appreciated.
>
> That is a good idea. And a button to reset to the values, gmplayer had when
> it started (if anything has changed in the meantime), would overcome the
> checking out problem even with only an "OK" button.
>
>> It would be good idea if all gui specific options do start with gui_
>> prefix.
>
> Yes, I think so, too.
>
>>> 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?
>
> Yes. I'd like to indicate - for example - that stop-xscreensaver is set (*)
> and thus will be used by gmplayer, but that it isn't set by the GUI.
>
> (*) because it is in my user config, or maybe - with another option -
> because
>     it's the coded default
>
> Ingo

Best Regards.