[Scummvm-devel] Options dialog design (long!)

[Max Horn]

Am 21.03.2004 um 16:35 schrieb <Torbjorn.E.Andersson at tietoenator.com>:

> Max Horn <max at quendi.de> wrote:
>
>> Consider this scenario: You start ScummVM into the launcher; you open 
>> the
>> global options dialog. In here, you switch to the 2xSAI filter, then 
>> close
>> the dialog. The kTransientDomain gets updated accordingly. Now you 
>> start
>> Monkey Island by double clicking it in the launcher. For it, you had
>> explicitly set the graphics mode to "AdvMame3x".
>>
>> Question: Which graphics mode should Monkey Island use now? 2xSAI or
>> AdvMame3x ?
>
> I would expect AdvMame3x. I see the global options as default settings 
> which
> the per-game options may override if they wish to.

OK. Still would like to know what yet other people think :-)

>
>> One possible solution for the latter problem would be to only allow
>> editing the permanent settings. That is, make the hot keys change the
>> settings in the config file, too (the opposite, only allow editing the
>> temporary settings, seems undesirable, since this way the user has no 
>> way
>> to edit his config file, short of using a text editor).
>
> I don't know... I always saw the hotkeys as a sort of preview of the
> different modes, and if I decided I liked it I would change the setting
> permanently in the config file, or through the GUI. (Well... actually I
> wouldn't use the GUI myself, but that's a different story. :-)

A "preview" ? Interesting view of the matter :-). I always viewed 
hotkeys as a convenient shortcut to access certain settings without 
having to use the GUI.

>
>> The first problem ("inconsistency") can be solved by updating the 
>> dialog
>> contents on the fly whenever settings get modified (e.g. via a 
>> hotkey).
>> That then leads to the question: should changes made in the (global)
>> options dialog be *immediately* activated, or only after pressing an 
>> "OK"
>> button? Both approaches have merits:
>
> Immediate activation doesn't seem very natural to me.
>
> I was going to say that I've never seen any other application use it, 
> but
> then I remembered that the music volume slider in the Broken Sword 2 
> options
> dialog does that. Hmm...

Heh. Actually, *all* applications I regularly use do it hat way. Of 
course they are all Mac applications, maybe that's why (Safari, 
Terminal.app, BBedit, Mail.app, Snak, iChat, XCode)... hm actually, 
Mathematica and FireFox are different. :-)


> It might be worth noting that in Windows, the volume setting dialog 
> uses
> immediate activation, while the dialog to change screen resolution and
> colour depth does not.

So what? I think it's a very bad idea to argue such things soley based 
on "how XYZ does it". Windows (still) has some very very bad UI 
mistakes in it, IMO (I don't say this is one, nor do I claim OSX or 
Linux were much better; I just want to point out that just because one 
of them does it doesn't mean it's the best way; also, what is the best 
solution for one product might be a bad solution for another).

Sadly, that's more or less the kind of reply I expected yet hoped 
wouldn't come: one based on a) what you are used to and b) what other 
systems do... yet none of the concerns I raised are addressed :-).

I'd appreciate if you could at least explain how you would address the 
various problems and inconsistencies I mentioned... ? If you consider a 
"hotkey" to be a "preview", then how do you resolve these situations:

1) User opens options dialog, changes resolution, closes the dialog 
with "OK" (this one is easy)

2) User changes graphics mode with hotkey, opens options dialog (what 
setting should be displayed?).
    If you answer "the active setting", what should happen if Save/OK is 
pressed?
    If you answer "the setting from the config file", what should happen 
if the user does nothing and presses "OK" ? What if he changes the 
choice and presses "OK"?

3) User opens options dialog, then while it is open uses a hotkey to 
switch graphics mode. See 2) for questions

4) User changes graphics mode with hotkey; opens options dialog; 
changes graphics mode in popup; uses hotkey again; now closes the 
dialog. Which graphics mode will be active, which will be stored into 
the config file?



>  Of course, changing screen resolution is much more
> jarring than changing from, say, one 2x graphics filter to another...
>
True. Note that the very same things are changed instantly by the Mac 
OS X System preferences: If I choose another graphics mode, it'll 
switch immediately. No problem there, either: if I do nothing for 10-15 
secs, or press ESC, everything is reverted. So even if my display is 
garbled and I can see nothing, I have no troubles.

I think we see a philosophical difference here, too. Mac traditionally 
tries to avoid "modes", that includes modal dialogs. THe preferred way 
is to have everything modeless if possible, that includes prefs 
dialogs: they are ideally a normal window like any other, and you can 
keep it open and continue working. Personally I find that very natural 
and also very useful, esp. when experimenting with the prefs of a new 
program.

However, while this is what I am used to, it is *not* the reason I 
propose it. I tried to explain the actual reasons in detail in my 
DESIGN document :-).


Cheers,

Max