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

[Max Horn]

Am 21.03.2004 um 18:53 schrieb <Torbjorn.E.Andersson at tietoenator.com>:

> Hmph... I shouldn't type email addresses when I'm tired. One more
> attempt to get it to a mailing list that actually exists... :-)
>

;-) Welcome in the club, brother...


> Max Horn <max at quendi.de> wrote:
>
>> 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 wasn't trying to say that. I was trying to figure out where my
> expectations may have come from. And Windows is the only OS I've used
> that had reasonable support for changing resolution/colour depth on the
> fly. (My old Mac Plus didn't support this, for some reason. ;-)

Fair enough!

> Making no attempt to be consistent, this is the behaviour that would
> seem least unnatural to me:
>
>> 1) User opens options dialog, changes resolution, closes the dialog
>> with "OK" (this one is easy)
>
> Barring catastrophic failure, I would expect the resolution to be what
> the user selected in the dialog. (Though given my background, I 
> wouldn't
> expect it to happen until after I press "OK".)

Aye (I said this one was easy, didn't I <g>)

>
>> 2) User changes graphics mode with hotkey, opens options dialog (what
>> setting should be displayed?).
>
> As I said before, I wouldn't expect the hotkey to change the config 
> file.

Just to clarify that: neither did I suggest it should (I did mention 
the possibility, but my proposal didn't include this).

>
> In a way, I'd like to see both the current setting (from the file) and
> the new setting (defaulting to what is currently used). Might not be a
> workable solution, but it'd be nice to have some sort of indication 
> that
> the old setting is about to change.

Actually, that's exactly the kind of hack I want to avoid. To use your 
argumentation, how many application do you know which do such a thing?
IMO, this is a only a "workaround" for the problem, trying to cure the 
symptoms, instead of trying to fix the cause :-). Besides, a workaround 
which if implemented a) doubles the size of the UI (every element has 
to be there twice), and b) makes usage a lot more complicated. We'd 
have to explain to users why all their settings are there twice (or 
actually, four times: active global settings, permanent global 
settings, active game settings, permanent game settings)

>
> (In the "Edit game" dialog, I would always expect to see the settings
> stored in the file, though, but that's a different case, I guess.)

Indeed, a different case: you aren't editing active settings here 
anyway, making it a very easy one, luckily.

>
> Re-reading what I've written, I think pressing "OK" would update the
> file and leave the current mode unchanged.
If no changes were made. But my question went on, to quote myself:
   'What if he changes the choice and presses "OK"?'

And to complicate things some more, consider this scenario:
  ScummVM starts in plain 2x mode. Using hotkeys you switch to 
AdvMame2x. You open the options dialog. By your proposal, it would 
still display the settings from the config file there ("2x"). Now the 
user chooses "1x" in the popup; then chooses "2x" again. And closes the 
dialog.

What should happen?


>
>> 3) User opens options dialog, then while it is open uses a hotkey to
>> switch graphics mode. See 2) for questions
>
> I wouldn't expect the setting to change. I'm not used to seeing dialogs
> that react to things that happen "behind their back", so to speak.

If you use dialogs which are modeless, that's how they always behave 
(displaying changes "made behind their back", as you put it). Of 
course, modal dialogs won't do that. But then, how many apps allow 
making changes "behind the back" of a modal preference dialog via some 
hotkeys ? I can't think of many (well I guess in windows, you can have 
the display system prefs open, and then via some 3rd party tool change 
the resolution?).


> When the user presses "OK", I'd expect the setting shown in the dialog
> to be saved/used, not what happens to be active at the time.

OK, so now I understand why you think of the hotkeys as "preview": 
essentially, while the options dialog is open, they are indeed 
completely reduced to "preview" keys, because when you click "OK", any 
changes you made since the options dialog was opened are lost.

But what if I cancel? Should "Cancel" do nothing, or should it restore 
the settings as they were *before* you opened the dialog?

Also, same question as above: I open the dialog, it shows "2x", I use a 
hotkey and swithc to "AdvMame2x". I select "3x" from the popup. I 
select "2x" from the popup. I close the dialog... what happens?


>> 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?
>
> The first half is like question 2. The config file and the current mode
> would not agree. The dialog may default to the current setting, but
> it'd be nice if there was an indication that it's not the same as in 
> the
> config file.

First you were saying the dialog should display the config file 
settings, now it should display what is current? Which one did you mean 
now, or did I just misunderstand you here or before?

Actually, since you are arguing for "OK" to alter the config file, the 
only logical thing to do would be to display the config file settings, 
and *not* the current settings, else using the "preview" hotkeys would 
cause a changed config file to be written if you use them, then open 
the options dialog and close it again immediately.


> The second half is like question 3. The dialog setting would remain, 
> and
> when pressing "OK" that's the one that'd be stored/used.

And what if Cancel is pressed?

BTW, implementing your proposal will increase the complexity of the 
config manager even more (though that shouldn't be a reason to alter 
our decisions).



> (Mind you, I still keep my .scummvmrc write-protected because once I've
> found the settings I like, and sorted the games in what seems like a
> logical fashion to me, I don't want some clumsy user changing them by
> mistake. Particularly not if that clumsy user happens to be me. :-)
>
:-)


Cheers,

Max