Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure

[h.g.muller at hccnet.nl]

Op Wo, 12 februari, 2014 10:38 pm schreef Yann Dirson:

Hi Yann,

I will move GNU SHogi to the top of my priorities list this weekend, as
otherwise I just don't get to it. I went sort of manic on XBoard the past
few weeks, as I finally figured out how to do one of the features that was
still on the wish list for the GTK version (ICS output not in the x-term
but in its own dialog window, where it can have appropriate callbacks).
And then I got distracted by another pet-project of mine, on-the-fly
tablebase generation.

Let me first comment on (some of) your remaks on XBoard-experimental:

>
> * games defaulting to hachu (@chu and @sho) look OK
> * games defaulting to gnu(mini)shogi require xboard support, I'll
> upload a gnushogi master snapshot into experimental as well; they work well
> with the correct binaries in $PATH
> * @mini should I think default to japanese theme
Mini-Shogi is not an officially-defined variant of XBoard, and thus needs
some user configuration to be played. In cases like that, it seemed best
to separate the theme config file from the rules config file. (I guess the
same in principle holds for Sho Shogi, but I probably figured that there
would be no interest outside the traditional Shogi community for that
anyway. While for mini-Shogi I see a good future, provided that people get
the opportunity to play it in a 'kanji-free version'.)

The need for user rule configuration would disappear completely if GNU
miniShogi would use the engine-defined-variants feature of XBoard-exp,
however, and I think this is the way to go. I should simply announce

feature variants="mini,5x5+5_shogi"

and respond to the "variant mini" command with

setup (P.BR.S...G.+.++.+Kp.br.s...g.+.++.+k) 5x5+5_shogi
rbsgk/4p/5/P4/KGSBR w 0 1

Then it could be played by simply selecting "mini" from the New Variant
menu, and no rule configuration would be needed anymore. The 5x5+5_shogi
would only be mentioned in the variants feature for compatibility with
older interfaces and older engines. (E.g. if you want to play engine vs
engine, and the opponent engine would not support 'variant mini'.) Then
only theme configuration would remain, and you could use @shogi for that:

xboard @shogi -fcp gnuminishogi

would overrule gnushogi as default engine specified in @shogi.

> * @xq board drawing is messed with large window sizes here,
> although OK with smaller window sizes (see http://imagebin.org/292981),
> otherwise seems OK

That is a matter of the size of the bitmap provided for the Xiangqi board.
XBoard cuts tiles the size of a square from this bitmap. For a square grid
of NxN squares that would in principle allow cutting 2Nx2N squares out of
it before you start to see the next grid line, but with the diagonal lines
in the Palace you already see artifacts when the square size gets >N.
These are not very annoying, however. My attitude was pertty much that if
people would think the board is too messy, they should simply switch to
smaller square size. In older XBoard (before it used Cairo) the only sizes
for which there were built-in westernized Xiangqi piece bitmaps were 33,
49 and 72 anyway, and the bitmap of teh Xiangqi board was made with 49x49
grid.

> * I feel .desktop files for shipped confs would be
> needed to make them more visible to users

Indeed, the confs are only useful from the command line. OTOH, confs can
be combined on the command line, which is useful when they configure
different aspects (game rules, board theme, engine). It would be hard to
provide desktops for every possible combination of those. But if there are
a few obvious combinations of theme + rules + engine (e.g. because GNU
also features an engine, such as with GNU Shogi), we could make desktop
files for those.

>
> * Tried Mighty Lion by starting "xboard -fcp hachu -scp hachu" and
> selecting that variant, looks like hachu crashed (xboard -debug output
> attached for comment by HGM, hachu is current master, ie version
> 0.17-3-g3460d0c).  The same technique is OK with Sho and Chu.

OK, I will have a look at that.

> * Trying to switch to Dai or Tenjiku is refuse with "Engine did not send
> setup for non-standard variant" * Maybe a @hachu conf would be useful for
> easy access to those games ? Maybe better shipped by hachu itself ?

The current XBoard does not support Dai or Tenjiku, and could not be made
to support them even through user configuring. The number of piece types
needed for thos games exceeds XBoard's current maximum (44 piece types,
which was already doubled compared to 4.7.x in order to support Chu
Shogi). Only the WinBoard 'Alien Edition' fork currently supports those
variants (as well as Dai Dai, Maka Dai Dai and Tai), but the piece images
are constructed from scratch in the WinBoard front-end in the 'mnemonic'
theme, so this does not work for XBoard.

In addition, Tenjiku is not fully implemented in HaChu yet. The move
generator still doesn't do 'area moves'. My original plan was to first
finish the move generator for all variants (which would also require me to
do hook movers fot Dai Dai and larger), before starting to worry about
search and evaluation, but then people started to push me for quickly
getting a working Chu, and I never got back to finishing the Tenjiku.

This exposes a weakness of the engine-defined variants protocol: an engine
can claim to support variants xxx and yyy, but as XBoard has no idea what
these entail, it cannot realize that it is not able to support them. It
only gets that info from the engine after the user selects the variant, in
the 'setup' command. Only at that point XBoard can discover it is not able
to support the variant, for a number of reasons (too-large board size, too
many piece types, parent variant unknown, and of course errors in the
setup command). This might seem strange to a user that doesn't know in
detail how things work. But to prevent it XBoard would have to probe the
engine for every variant, which currently can only be done by switch it to
that variant, and waiting for the 'setup' response, to judge from there
for of the variants it wants to display buttons in the New Variant dialog.
Perhaps I should do that, although I really hate to mess with an engine
that way.

>
>
> * Switching to Chu from "xboard -fcp hachu -scp hachu" enlarges the
> window while keeping the same tile size, which always make it too big for
> my screen, since xboard already starts up using the full screen height for
> 8 tiles.

This is still a legacy from the pre-SVG era, when the tile size could not
be changed at all during a session. Now that we use Cairo the board window
is resizable, but the clocks and other elements above the board still are
not fully so (even in Xaw they won't automatically switch to the font that
would belong to the new size, and in GTK they completely refuse to shrink
below the initial size). I guess it would make sense to keep the total
board-width fixed after a variant switch, though. I will alter XBoard that
way.

>
> * I guess xboard shipping chu and sho confs make those in hachu.git
> redundant ?
>

Yes, it would. I think the future will be to distribute those confs with
the piece and board graphics as separate packages, apart from XBoard or
the engines.

H.G.