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

[Jamieson Christian]

I hope this isn't too little, too late, but I'm just coming back on the
scene after a while away.

After reading through the doc, these are my opinions on the matter.

----------
All hotkeys should be disabled whenever the launcher or an in-game menu is
active. My arbitrary speculation is that (1) very few people are going to
try this, and (2) the ones who are probably aren't doing so for any good
reason. The cited example relates to changing the display mode with a hotkey
while the menu to set that very same option is current visible. In that
case, why bother with making the hotkeys available? Are there any other
situations in which availability of the hotkeys would make any more sense? I
can't think of any.

So... I vote for disabling hotkeys in the Launcher or in-game menu.
EVENT_SCREEN_CHANGED events be damned. (Hopefully I toss that comment off
without having completely misunderstood the proposed EVENT_SCREEN_CHANGED
solution.)

----------
All hotkeys and in-game option changes should modify the persistent options
for the current game. HOWEVER, I think if this is the case, saving the
options changes to the config file should only occur on exit. The reason is
twofold. First, in the case of a normal session, users won't notice the
difference between saving immediately and saving once they exit out. Second,
in the case of a contingency situation that requires force-killing ScummVM,
the options will never get saved out. If the force-kill was the result of a
bad options setting, that option won't get changed.

Granted, about the only option I can think of that might require a
force-kill would be the graphics mode. In that case, we should really
consider doing what MacOS and Windows95+ do: change the graphics mode, pop
up a dialog box saying "Click here if the mode switched okay", and if it's
not clicked within 10 seconds, switch back to the old graphics mode.
(Windows XP is even smarter about this: it remembers which graphics modes
have been accepted as usable, and doesn't keep popping up the dialog box
every time the user switches to that mode. Would we want to do something
similar?)

If we did that, I would see no problem with saving in-game changes
immediately.

----------
Acknowledging that some people might not WANT their in-game changes
persisting to subsequent sessions, I would recommend an option for "Remember
in-game changes for future sessions." This would be a global option (in the
"Misc" tab), and also a per-game option (with "Remember", "Don't Remember",
or "Default Behavior" as options). The global out-of-the-box default, I
think, should be to save in-game changes, for those users who might get
confused if change they made don't show up the next time around. (It makes
more sense for the game to behave just the way you left it last time, though
advanced users might not want this to be the case.)

This is basically a union of the two solutions proposed in Fingolfin's
document. Depending on what the user selects, changes made by hotkey or
in-game menu will either be transient (temporary) or permanent for that
game's settings.

----------
Regarding this business of changing global options in the Launcher right
before launching a game that is going to override them anyway. I propose a
"kAppTransientDomain" into which any Launcher changes are stored. Only
changes that depart from kApplicationDomain would be stored. Then, when a
game is selected, settings in kAppTransientDomain would be compared with the
specific game domain's settings. If anything varies, a message box comes up
saying something like, "You just made global changes that are different from
this game's settings. Would you like to use the game's settings or the
global settings?" If the user elects to use the global settings,
kAppTransientDomain would take precedence over the game's domain (in between
Steps 1 and 2 in ConfigManager::get(), config-manager.cpp lines 310-314 at
the time of this writing). Otherwise, kAppTransientDomain is discarded.

IF the user selects to use kAppTransientDomain (modified global settings),
those settings should get written into the game's domain per the "Remember
changes for future sessions" option proposed above.

    -- Jamieson (sf.net: Jamieson630)