XBoard themes

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!