Re: [XBoard-devel] packaging strategy,board themes

[h . g . muller]

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?