Op Ma, 2 december, 2013 4:07 am schreef Arun Persaud: > > I think it would be nice, if XBoard and Winboard can handle this the > same way and can also use the same theme files, so that we don't have to > create different theme files for the two versions. > Well, I am not sure how sensible that is. The problem is different, because Windows software is not distributed in packages with a dependency scheme that are supposed to automagically install themselves in a way that things work. WinBoard users furthermore would never start from the command line, so that things like 'xboard @chu' for invoking a settings file chu or chu.xop are not convenient. WinBoard also doesn't have the concept of a default engine, but starts through a separate one-time dialog known as the Startup Dialog.
Currently in WinBoard the board themes are stored as lines in a multi-line option -themeNames, which itself resides in the persistent settings file. Similar to the options -first/secondChessProgramNames and -icsNames. Each line of this multi-line option is parsed as a command line, and can thus contain an arbitrary number of command-line options. Basically each line is a settings file, leaving out the linefeeds (which are ignored in settings files anyway, only there to enhance readability). We could also adopt this scheme in XBoard, but the problem is how to get an extra line added automatically to the -themeNames value stored in the user settings files. I added an option -installEngine of a new class of options that would not set a value, but append to the existing value. This is wrought with problems, however, as the way I have it now, it would only work for the user that ran xboard with this option: the new value of the -firstChessProgramNames on which the option acts, with the appended line, would only be saved back to the settings file ~/.xboardrc of that user. SO that it only works for the user that actually did the install of the engine (or theme) package. While in fact you would want that when a system administrator installs a new engine on the system, it would appear in the engine list of all users. Adding an -installEngine option to the master settings file (/etc/xboard.conf) AFTER the option that redirects reading settings to the user's settings file would accomplish that, (first reading the engine list from the user settings file, and then appending to that), but in the current way of operation XBoard would never save on the master settings file. So it would require new code in the processing of the -installEngine option to do such writing. In fact this would require a completely new option class, to append an option to the master settings file, which then could be used to get the -installEngine option there for the new engine, by running xboard -installMasterOption "-installEngine fruit -fUCI" -autoClose called from the Fruit install script. The XBoard runs of every user would then see that added line in the master settings file afterwards, which would add 'fruit -fUCI' to their list of installed engines. Of course you only want that to happen the first time XBoard encounters that line, or they would get many duplicates. This can be combatted by only adding lines that did not already occur in the multi-line option to which you add. But that is unfortunately not enough: There could be users that do not want the installed engine in their engine list. E.g. because it is a Shogi engine, and they are only interested in Chess. It would be extremely annoying to such users if, every time they deleted the engine from their list of installed engines, it would re-appear on the next run. So the -installEngine option must somehow be a one-time thing. Implying there should be some sort of mechanism that can check if XBoard has already seen the same -installEngine option before, and ignore it when it has, irrespective of whether the user already has the mentioned line in the option to which it woud append. Like a date stamp. E.g. "-installOption foo" could be made to add two lines to the master settings file: -date TIMESTAMP foo On processing the -date option XBoard would remember the TIMESTAMP in a variable, like it does for any option, so that it would be available while it processed the subsequent 'foo'. And if "foo" was in fact "-installEngine fruit -fUCI", the action of the -installEngine option could be made dependent on the comparison between the stored value of the last-encountered -date option and the value of a similar -saveDate option in the user settings file recording the time that file was written (i.e. it would be simply ignored if the latter is earlier, and append to the -firstChessProgramNames otherwise). The -saveDate setting would then be updated by XBoard just before saving the settings. (Of course the -saveDate stuff could also be based on the actual modification date of the user settings file, but that would require all kind of platform-dependent stuff to figure out. So it might be simpler to just store it inside the file as an option setting.) Anyway, this rather contrived scheme would allow information to trickle down from an engine-install package to the user settings files in the desired way. And what holds for engines basically holds without modification for board themes as well; as far as XBoard is concerned the engine list and themes list are just multi-line options. (And in WinBoard, the Board Themes dialog is in fact just a cloned Load Engine dialog.) It just means that there should also be an option -installTheme for appending a line to the -themeNames multi-line option just like -installEngine appends to the -firstChessProgramNames option. I.e. of the same, new 'ArgInstall' class, but referring to a different option. The master settings file would accumulate lines to auto-install engines, with their date stamps, for each engine that was installed (and was clever enough to use this mechanism by calling XBoard in its install script). I guess it would be neat to also equip XBoard with an option that could delete such lines, when the corresponding engine is uninstalled. OTOH, this is problematic, as just deleting the installEngine line from the master settings file would not delete the engine from the engine lists in all user settings files. To make uninstall work sensibly, we could define a certain invalid value for the -date option stored in the master settings file, so that when the stored -date value in XBoard (i.e. the value last-seen -date option) would have that value, the "-installEngine foo" option would actually work in reverse, not appending the line to the engine list, but deleting it when it was present. A new option (of a new type) "-removeOption foo" (used in engine uninstall scripts) would then scan the master settings file for a line "foo", and replace the TIMESTAMP in the -date option on the line above it by this invalit date code. Thus instructing future readers of the master settings file to reverse the action of the install option presumably present on the foo line, and making it uninstall the engine. Of course we would also have to prepare for cases where an engine is re-installed after uninstall. So "-installOption foo" should only append the line "foo" (with accompanying date stamp) to the master settings file if that line was not already there. But if it was there, it should modify the date stamp above it to the current date if it was invalid. Does this sound reasonable? Or am I going completely overboard on this now?
