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

[Yann Dirson]

First a new small bug: have hachu played a full Chu game, probably
after having selecting a white piece, and noticed that the dot stayed
there till end of the game: http://imagebin.org/293529

On Fri, Feb 14, 2014 at 11:48:16AM +0100, h.g.muller at hccnet.nl wrote:
> > * 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.

I see.  However, the problem of giving easy access to all those
GUI-only users not willing to dive into manpages to discover that,
will still be there.


> > * @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.

Hm, with today's large screen sizes, it's not very friendly to require
keeping a small window.  What about using SVG there instead ?


> > * 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.

Or maybe provide a launcher to select theme/rules/engine and run
xboard with proper options, at least until those are made selectable
from within xboard itself ?  There are tools to help for this
(remember seeing new packages in Debian for this months if not years
ago), but I can't find the right keywords to find them again.


> > * 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.

Right.  Maybe a more user-friendly message would be enough, and you
could keep the detailed reason for -debug ?


> > * 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.

Makes sense.  We'll have to find a correct set of relationships to
declare between them.  I guess it makes sense to have them depend on
xboard and recommend the default engine.