GUI does not reflect command line config overrides

Logged In: YES
user_id=12935

My prefered solution to this "bug" is to just remove
SCUMMVM_SAVEPATH, which IMO is an aberration that
should never have been added in the first place.

Logged In: YES
user_id=577918

I'm in favor of removing SCUMMVM_SAVEPATH, but I'm usually
running ScummVM on a UNIX-ish system where each user has his
own ~/.scummvmrc file. On Windows I believe the scummvm.ini
file is always stored in C:\WINDOWS, and I don't know where
it's stored on a Mac.

Though I guess you could use the --config command-line
option to get around that...

Logged In: YES
user_id=1137597

I resolved for using SCUMMVM_SAVEPATH when creating a CD
with ScummVM, scummvm.ini and some games on it. I wanted it
to completely run from CD, but store the savegames in the
current user's profile.

So i created a scummvm.ini with relative paths for the CD,
passing it to ScummVM using the --config argument.

As the save directory depends on the current user, i use a
batchfile to set SCUMMVM_SAVEPATH =
%USERPROFILE%\ScummVM-Savegames before starting ScummVM.

However if you decide to remove SCUMMVM_SAVEPATH i'd really
appreciate if you add a command line argument for the
savepath instead.

Granted that i'm new to ScummVM, there might be other
solutions for my problem, so i'd appreciate any suggestions
for better solutions.

Logged In: YES
user_id=166507

scummvm --savepath=/blah/blah/ will do the trick

Logged In: YES
user_id=1137597

Thanks, that works.
But it works just the same as the SCUMMVM_SAVEPATH:
The given path is used by ScummVM, but is still not
displayed correctly in the GUI.

I guess i'll have to start reading the sources instead of
the readme.txt to find the latest tweaks... ;-)

Logged In: YES
user_id=577918

I've documented --savepath now. Thanks for pointing it out. ;-)

Logged In: YES
user_id=166507

For me it seems a correct behaviour. I.e. GUI reflect what
could be changed, that is config file value. There is no way
to change command line option or environment variable.

Logged In: YES
user_id=1137597

Actually you *can* change the savepath in the GUI.
After the change the new path correctly displayed and also
used to store the savegames. This works even if the .ini
cannot be saved.
However, if someone just goes to Options/Misc to check on
the location of his savegames, he'll get prompted the wrong
path.
So to me the behavior is correct, only the presentation is
flawed.

Logged In: YES
user_id=12935

Well, I'll look at the UI issue eventually. For now, ender, please
comment whether you have objections to removing
SCUMMVM_SAVEPATH.

Logged In: YES
user_id=1137597

I fixed the problem with my own build of ScummVM based on
the sources of the 0.6.1b release. It's working for me so
i'll share my changes.

Logged In: YES
user_id=12935

Assuming you wanted to attach a file, make sure you enable the "Check
to Upload and Attach a File" checkbox.

diff of the changes to config-manager.cpp

Logged In: YES
user_id=1137597

Sorry, i overlooked the checkbox.

Logged In: YES
user_id=12935

That patch doesn't apply over here on latest CVS. You should do patches
using the -u option, so they carry some context, and apply in multiple
versions of the source...

Anyway, that change isn't a proper solution to the problem ; it changes
ConfigManager::get() to work incorrectly. A proper fix would almost
definitiely be done in the GUI code.

Logged In: YES
user_id=1137597

I already thought so. My idea was just to make
ConfigManager::get() work like you would guess it does from
looking at ConfigManager::hasKey().
At first i had changed GlobalOptionsDialog::open() to look
for the transient savepath, but the second patch looked
better... ;-)

Anyway, thanks for your comment. I'm looking forward to
seeing the "real fix".

Logged In: YES
user_id=2715

Hmm, SCUMMVM_SAVEPATH is an interesting one. Really,
we should depreciate it since there is now a commandline and
config/gui option.

However some users may prefer adding a
SCUMMVM_SAVEPATH=... override in
their .bashrc/.profile/whatever. This is also useful for
system-wide installs.

I think it should probably be left in, since the codepath should
handle it the same as the cmdline switch - which has the same
issue at the moment. Updating summary to suit :)

Logged In: YES
user_id=166507

What is the status of this item?

Logged In: YES
user_id=2715

The situation is unchanged, the GUI still ignores
any path override via environment variable or commandline
option. Perhaps this should be moved to RFE?

There are two reasonable behaviours for this particular
situation:

A) Only display the editable savepath, ignoring the static
override, as we currently do. I think this is correct and could be
considered 'behaviour by design', but perhaps non-intuitive to
some users.

B) If an override path is specified and we do decide to display it
in the GUI, the field should simply be disabled to ensure the
path cannot be changed.... thus accidently saved to the config
file.

Personally I'm quite happy with it, but it would only be a few lines
of code to implement the alternate behaviour.

Logged In: YES
user_id=166507

Moved it to RFE. Same lowest priority.

Yes, logic is flawed here, and I think to prevent it best
would be to implement behaviour (B) and describe it in
documentation.

Logged In: YES
user_id=12935
Originator: NO

This problem does not just affect the savepath, mind you, but *any* command line config. Be it the music volume or the subtitles settings.

This nicely demonstrates one of the pathologies that occur when you mix command line options and GUI options; the former being completely transient, the latter usually being persistent. I am not sure if there is a proper way to resolve those in a really satisfactory way, ever.. :-/

Let's think about it: The user fires up ScummVM via the command line with some special (transient!) settings, but *without* specifying a game. Why would he do that, normally? The only plausible thing I can come up with is: To start a game for which he doesn't recall the precise target name. Fine.
Would he open the options dialog in that case? Probably not, *unless* he wanted to change some additional settings before running his beloved game, some settings for which he didn't recall the command line options and/or was too lazy to type them all in.

So, I imagine in that case he would want:
1) the additional changes (made via the GUI) to be transient, too, not persistent (as usual)
2) his command line options to have precedence over the game/target specific settings
Hence, one might consider simply turning of persistence of the global options dialog in the launcher when any command line options are present. That should work fine for most users:
* nothing changes if you never use special command line options
* nothing changes if you use command line options + a target
* it would be similar to Enders' "plan B" from below, only that the user could still use the options dialog, for temporary settings

Of course, this approach is far from perfect, too. But in the end, the user could *always* come up with some odd combination of effects should he want to. For example, specify a custom "--savepath", then run ScummVM, open the options dialog, and set yet another savepath. Which would probably be a rather silly thing to do. Unless you consider the "CD with ScummVM" scenario mbauer0xff described below. Then again, in his scenario, the .ini is on a CD anyway, so it'd be read-only (and hence all settings transient) anyway.

A final suggestion: Ignore all (well, almost all, --config being the exception) config settings when running the launcher, possibly printing a message that we just did so. It would resolve the issue presented here completely and in a very simple fashion. Of course it would also make it impossible to use the "user specific savepath" trick mbauer0xff wanted to use. But then we could resolve *that* by using a standard savepath inside the user home dir under Windows, too (like we now do with the default config file location on windows, too). Kirben, would that be feasible/sensible (independent of the other thoughts mentioned here)?

Gah. I like none of these particularly. :-(