[XBoard-devel] packaging strategy,board themes

[h . g . muller]

I want to address the following problem:

I added Chu Shogi as a supported variant to XBoard. Currently only one
XBoard engine exists that can play this game: HaChu. Debian supplies
XBoard and HaChu in different packages.

XBoard can play Chu Shogi with Chess-style piece pictograms, from its
default set. (And IMO, this will be the only chance for this game to ever
acquire any popularity at all outside Japan.) However, there is an
existing group of perhaps a few dozen 'hard-core' western players, who are
used to the Japanese kanji representation, and consider anything else
herecy/sacrilege. This is not a problem, as the piece representation can
be set by the user to anything he likes, and a set of Chu-Shogi svg pieces
is now available.

The problem is how to distribute those pieces. An SVG piece image is about
10KB (and probably could be saved in an even more compact format), but Chu
Shogi requires 72 pieces. So we are talking about 720KB here, not
tremendously large, but also not completely trivial. Just adding it to the
standard XBoard package just because an extremely tiny fraction of the
users might want it seems wrong. We do include kanji pieces for Xiangqi
and regular Shogi, but these are games that have hugely more players on a
World scale then Chu Shogi. (And even there I have my doubts whether they
shouldn't be distributed separately; XBoard can be perfectly used to play
Xiangqi and Shogi in the western representation.)

This touches on the subject of board themes. The kanji pieces are in fact
just different (albeit radically different) piece images, and for ordinary
Chess the pre-Cairo version of XBoard also had many different sets of XPM
pieces floating around, with which we never bothered. But perhaps we
should set up web pages on the GNU website on which we collect such
alternative piece sets, and make them available for download as separate
'theme' packages.

For the moment I included the Chu-Shogi SVG set in the HaChu package,
together with an XBoard settings file for instructing XBoard to use them.
The idea is that people that want tu use XBoard for Chu Shogi would
certainly install HaChu as well, and then automatically get the kanji
pieces. It is not 100% sure they would want them, as they could be
perfectly happy to play it with the western pictograms, but at least the
fraction of HaChu users that would want kanji pieces will be vastly larger
than the fraction of total XBoard users. This solution is not ideal in the
long run, however, where other Chu-Shogi engines and other
Chu-Shogi-supporting interfaces will emerge (I heard an interface 'Omaha'
is already in the making).

The XBoard-specific piece support in the HaChu package currently consist of:

* A directory with SVG pieces, for installing as
$(datadir)/games/xboard/themes/chu/*.svg.
* A settings file 'chu', for installing as
$(datadir)/games/xboard/themes/conf/chu

The latter contains all the option settings needed to configure XBoard for
Chu Shogi, and use the kanji pieces. It also redefines the default engine
to hachu. To allow the settings file to specify the kanji pieces, a XBoard
was made to recognize a new symbolic filename: ~~/foo in a file option is
now interpreted as $(datadir)/games/xboard/foo. Also  new is that XBoard
will search for a settings file foo in ~~/themes/conf when the user types
@foo on the command line. (Before it only searched for a ./foo.) This
allows the user to play Chu Shogi against HaChu in kanji representation by
simply typing 'xboard @chu'.

One of the problems is how to find the XBoard themes directory when
installing the hachu package. This is the same problem we would have when
we create separate packages for board themes (as the current hachu package
is basically a board theme that also includes an engine). Depending on if
the user installed XBoard from source or binary package, $(datadir) would
be /usr/share or /usr/local/share. And this doesn't correlate with whether
he will be installing HaChu from source or binary. So it doesn't really
know where to install the svg pieces. And of course it could be that
XBoard is not installed at all; for pure themes it is unlikely people
would want to install them if not for XBoard, but for HaChu this is not
inconceivable.

I wonder how this could be solved. I added in -installEngine option to
XBoard to allow the hachu package to add HaChu to the engine list of an
installed XBoard without knowing where to find XBoard's settings files
(which in general would be individual user's files ~/.xboardrc anyway, for
users that already have been running XBoard). The idea is that an engine
package could run XBoard in its post-install script to have it add the
engine to its settings file (which it must know how to find). I guess a
similar option could be added to XBoard to actually move files: "xboard
-installFile themes/chu/*.svg" could prompt XBoard to issue the command
system("cp themes/chu/*.svg $(datadir)/games/xboard/themes/chu"). Would it
be an idea to implement such an option, or is this too kludgy?

With such a feature XBoard could be called by board-theme packages to move
the directory with SVG files to the ~~/themes directory it happens to be
using, and a settings file 'themename' to ~~/themes/conf to configure
XBoard for using that theme in response to the command 'xboard
@themename'. As the options specified in the 'themename' settings file
would in general be persistent, that would instate the theme for them
persistently until they select another.

This system of settings files would not allow them to select a theme
through the menus, however. For that a (very general) file browsing dialog
could be added that parses any selected file as settings file, which
always starts browsing in the ~~/themes/conf directory.

This is a system quite different from what WinBoard uses, though. There
the theme settings are not in separate files for each theme, but stored as
lines in a list, (each line containing multiple options), the list itself
being an option -themeNames, stored in the settings file. This makes it
more difficult to add a new theme by installing a package (which would
have to be accomplished by adding a line to the -themeNames string in the
user settings file), but it makes it easier for users to add new themes
(as combination of option settings for board and piece colors, board
textures and pieecImageDirectory) through the menu.

So I am not sure what would be the best way to go here.