Nice! I would say this fixes a subtle bug in the old code. The change is definitely an improvement.
On Fri, Aug 6, 2010 at 5:36 AM, h.g. muller <[email protected]> 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! > > >
