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

Lobster lobo at lobs.sytes.net
Wed Apr 27 02:41:04 CEST 2011


On 27/04/2011 11:18 a.m., Ivan Kalvachev wrote:
> 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

Why not just a tick box by or near the ok/cancel that says "Save current 
settings to config file"
or some thing along those lines?

just my 2 cents.





More information about the MPlayer-dev-eng mailing list