[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XBoard-devel] updated master and v4.4.x
From: |
h.g. muller |
Subject: |
Re: [XBoard-devel] updated master and v4.4.x |
Date: |
Fri, 06 Aug 2010 14:36:25 +0200 |
I am reporting the following patch in this list, because I think that it is
something
Tim will appreciate. We have been discussing settings files several times,
and Tim correctly pointed out how much milage WinBoard gets from the way
the settingsfile was implemented. Well, through a subtle change, we now can get
even more. (And XBoard now uses it too...)
The way an -ini or -settingsFile argument used to be treated in WinBoard
(4.2.7, 4.4.x)
was (in pseudo-code) as follows:
fullname = PATH(settingsFileName);
FILE *f = fopen(fullname);
if(f) {
ParseSettingsFile(f);
settingsFileName = fullname;
}
This now has been changed in master (the future 4.5.0) to:
fullname = PATH(settingsFileName);
FILE *f = fopen(fullname);
if(f) {
settingsFileName = fullname;
ParseSettingsFile(f);
}
This subtle change makes that the name of the settings file now can be
redefined
from within the settings file, by including another -ini or -settingsfile
option in it.
With the old code settings files could be used recursively, but -ini option
inside
them would in effect be treated as indirection settings files (@file), because
the effect they had on changing the settingsFileName (where settings would be
saved later) would be undone by the later assignment of fullname to it.
So only the outermost ini file, as specified by command-line options or
default,
would be effective for saving.
In the new method the last-encountered -settingsFile option will prevail as the
file used for saving (if it existed). This allows redirection of the
settings file
from the default settings file (winboard.ini in WB). The nice thing about
this is
that having such a redirecting -ini option in it, will protect the default
settings file
from overwriting, when saving the settings. They will now go to the
redirected file.
As a result, the redirecting -ini option will remain in the winboard.ini,
rather than
disappear because of overwriting, so the saved settings will be sought in the
place they were saved on a restart.
This now makes the possibilities for configuring WinBoard even more versatile.
I just prepared a binary install for Chinese Xiangqi customers. They would
like
-variant xiangqi to be the default, of course. In the old way this could
only be done
by options in the command line for starting up WinBoard (e.g. in a shortcut,
directly including the option, or put it in an indirection file, and use @
to access
that). If you would put -variant xiangqi in the winboard.ini, it would
disappear the
first time they sved, as the variant is a volatile option.
But in the new way, I supply a small winboard.ini with the install, which
redirects
saving by including -ini settings.ini at the end, and contains -variant
xiangqi.
So in effect this mechanism allows redefinition of the default values for
volatile
options, by setting those before the redirection with the -ini option. But the
reverse is possible as well: you can effectively turn options that are saved
with the settings into volatile options. For that you have to include them
in the winboard.ini file AFTER the redirecting option. The processing of the
options in the files still takes place in the recursive manner, so even if
another
setting was sved for that option, its occurrence after reading the settings
back
from the save file in the winboard.ini will reset their value, making the
saving
ineffective.
This mechanism can also be used to solve the security problem on multi-user
Windows systems. By specifying a redirection with a variable name, like
-ini %APPDATA%\winboard.ini (the equivalent to the XBoard -ini ~/.xboardrc),
in the winboard.ini master settings file will cause every user to have his own
settings file. The user can again apply this mechanism recursively, so that
from his own settingsfile in %APPDATA%
(= C:\Documents and Settings\{username}\Application Data\)
he can again redirect to another file for saving, and use his private
winboard.ini
for redefining volatle or persistent options to any fixed setting he desires!