Someone was willing to make the effort to create some nice SVG piece
sets for regular Shogi, Chu Shogi and Tori Shogi. As a result I was
forced to thin some more on how such 'themes' could best be distributed.
What seems to work reasonably well is this:
Each piece set comes as a tar ball, including the SVG piece images,
possibly some PNG board texture bitmaps, a Makefile with an install,
uninstall and dist target, a README file for author and copyright info,
and an XBoard settings file. The latter installs in
$(datadir)/themes/conf, where XBoard looks for 'indirection files'
invoked with the @ sign. So
xboard @chu
would run XBoard with a Chu Shogi theme, which does not only define the
graphics, but also sets XBoard to play Chu Shogi, redefines the default
engine as HaChu, and sets various rule modifications (e.g. adjudicate on
4-fold repeats rather than 3-fold repeats, switch off the 50-move rule).
To prevent these settings would leak into the persistence file, and be
used the next time, when the user might want to play orthodox Chess, it
also redefines the persistence file. That basically means Chu-Shogi
settings lead their own life, remembered from @chu session to @chu
session, invisible for other invocations of XBoard. This is basically
already how it is now, except that the HaChu engine is in the same
package as the theme.
But now there is an alternative Chu-Shogi theme, which comes with a
settings file called 1-kanji-chu, so that it can be instated with
xboard @1-kanji-chu
There is a subtle difference between this file and the @chu theme,
though: the latter is a 'general theme', the main purpose of which is to
switch XBoard to Chu Shogi, and in particular, use the persistent
Chu-Shogi settings. So the redirection to the persistence file
~/.xboard-chu-rc occurs at the end of the 'chu' file, so that (in case
this file already exists) all persistent settings, in particular those
associated with the piece and board graphics, will be overruled by the
user's preferences of his previous Chu-Shogi run. The specification of
the theme is thus only effective the first time that user uses @chu, and
acts as an altered default of a persistent option.
With @1-kanji-chu, the user requests a 'specific theme'. In this
settings file the persistent Chu settings are redirected before the
theme is specified, so that the latter will overrule the theme stored in
the persistence file. Settings desirable, but not strictly necessary to
Chu Shogi (such as whether promotions invoke a popup or not) can still
be put before the redirection, so that the persitence file prevails
there. This way the file can still be used to create a Chu-specific
persistence file with recommended Chu settings even when the user has
never used @chu before. But when he uses @1-kanji-chu, he forces the
theme of single-kanji tiles, which then would become (Chu-)persistent,
so that next time he invokes XBoard with @chu this theme will be used.
This solves the problem of retyping long and cumbersome theme names (as
themes are bound to have, to meaningfully distinguish them) for
command-line users. After having used the specific theme file once, they
can simply swicth back to typing @chu each time they want to play Chu.
To force a switch back to the default Chu pieces now distributed with
HaChu, there should be another settings file included to launch it as a
'specific theme', e.g. through @default-chu. So the package with the
default Chu-Shogi theme should contain a general theme file 'chu' as
well as a specific theme file 'default-chu'. Or perhaps any theme should
also contain that config file 'chu'. (But this will cause trouble with
uninstall, unless we exempt that file from uninstall, which also seems bad.)
Of course it would also be nice if newly used themes would automagically
become available in the 'Themes' listbox of the View->Board dialog, so
that they can be selected there. For this a similar system could be used
that already exists for adding engines: the make-install script of a
theme could call XBoard with the -addMasterOption "xxx" option to add a
time-samped line xxx to the XBoard master settings file. This line would
then be a yet-to-be-implemented option -addTheme THEMEDEF, which would
add THEMEDEF to the user's -themeNames list in his persistent settings
file when he runs XBoard for the first time after the theme install
(with that particular persistence file). This way newly installed themes
would automatically triccle into all his persistence files.
The equivalent of a general theme like @chu to a desktop user should be
a new .desktop file that starts XBoard with the @chu settings.
Commenst and suggestions welcome!
