On Fri, Aug 6, 2010 at 5:36 AM, h.g. muller
<address@hidden> wrote:
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!