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

[Yann Dirson]

On Sat, Feb 15, 2014 at 10:57:20PM +0100, h.g.muller at hccnet.nl wrote:
> Op Za, 15 februari, 2014 9:44 pm schreef 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
> 
> OK, this is a dot from the 'Show target squares' option, that apparently
> was not properly erased. This is always a bit tricky, because it can be
> that it is actually erased on the board, but that the corresponding expose
> event to actually update the display was never performed. (A check for
> that is to flip the view, because that redraws the entire board. But I
> guess it is too late for that now.)

I wouldn't think so, since during the game arrows ane pieces were
drawn at the same place, and the dot was even drawn on top of pieces
IIRC.


> It would be helpful to know if you were playing with legality checking on
> or off: when it is on XBoard itself marks the target squares with dots
> when you 'lift' a piece, drawing on its internal move generator and rule
> knowledge, while when it is off it follows the instructions sent to it by
> the engine for marking the squares (and HaChu uses that).

So it seems I have legality checking on by default with @chu, but not
with @shogi.  I assume GNU Shogi misses the necessary support.


> It would also be helpful to see the entire game, and know the moment when
> this dot first appeared. (Presumably when a piece was lifted that could
> move to that square.) Or was the dot there already when the game started?

The dot was there at first.  I must have clicked on one piece or 2 to
show my son how things worked, then started two-machines mode with the
dot still displayed, and it stays here as the engines start to play.
Easily reproducible, in fact.


> >
> > 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.
> >
> When the engine sends the 'setup' command, the user would not have to
> worry about rule knowledge. And I think I also made it such that when an
> engine does not report it plays variant normal of fischerandom, that
> XBoard would automatically switch to the variant that the engine does
> play.

Oh I see.  It does work, although it is affected by the lack of tile
resize I already noticed, so "xboard -fcp shogi" shows a shogi board
with the bottom row off-screen.


> That leaves setting the theme. The various theme 'components', such as
> pieceImageDirectory and square background textures or square colors can
> already be set through the GUI, but it is a bit inconvenient that he would
> have to set all aspects separately. In WInBoard I solved this by adding a
> View->Themes dialog, very similar to the Load Engine dialog. (Cloned from
> it, in fact.) The idea is that the user sees a list of theme names where
> he sees engine nick-names in Load Engine, and can select those by clicking
> them. A theme (like an engine) is a line in a multiline option stored in
> the settings file (-themeNames in stead of -firstChessProgramNames). The
> line consist of a sequence of XBoard options, processed as if they formed
> a command line when the user selects that theme. The rest of the dialog
> contains controls to set options that define the theme (basically what is
> now in the View->Board dialog), plus a text entry for the 'theme name'
> that is initialized empty. If the user uses the dialog not to select an
> existing theme but to modify individual settings, XBoard would just
> implement the new settings on 'OK'. But if he provided also a theme name,
> the combination of settings would forget into a line, and added under the
> given name to the list of themes, so next time he can recall it with a
> single click.
> 
> I recently added a new class of options to XBoard (of which -installEngine
> was the first representative), which would add their value (a text string)
> as a new line to the end of a multi-line option (-firstChessProgramNames,
> in this case). I could make another such option, -installTheme, which
> would add to -themeNames. This could be used to make newly installed
> themes automatically appear in the theme list of all users, by in the
> install script of a theme package write the command
> 
> xboard -addMasterOption {-installTheme '"Oriental Chu" -pid ~~/themes/chu
> -lightSquareColor #FFE040 -darkSquareColor #FFE040'} -autoClose
> 
> which then would add the line
> 
> -installTheme '"Oriental Chu" -pid ~~/themes/chu -lightSquareColor #FFE040
> -darkSquareColor #FFE040 -variant chu'
> 
> at the end of the xboard.conf master settings file, so that every future
> user would get to see it, and get the line
> 
> "Oriental Chu" -pid ~~/themes/chu -lightSquareColor #FFE040
> -darkSquareColor #FFE040
> 
> added to his -themeNames list, so he could select it with a simple click.
> Basically the line to be added contains the same as what is now in the
> conf files like ~~/conf/chu, except on a single line.

Wouldn't it be easier to just drop an "OrientalChu" file in an
xboard.conf.d/ dir, so that installing a new theme does not require
running xboard ?

It would also have the nice property that, when xboard ships a new
xboard.conf, it does not overwrite the previously-added themes.
Debian has support for warning the admin when upgrading, and offer her
to select one to keep or to go for manual merge; or we could add an
update-xboard-conf command to reconstruct ourselves xboard.conf each
time xboard.conf.d/ has changes; but it just makes things unnecessary
complicated in this case.


> > Hm, with today's large screen sizes, it's not very friendly to require
> > keeping a small window.  What about using SVG there instead ?
> >
> 
> The texture become rather ugly on sizing, when they are SVG. A better
> solution would be to simply provide a very large board bitmap. For en
> even-colored board, this compresses to almost nothing, but for the plywood
> default theme it might be several MB. But that still isn't a big deal,
> nowadays. Especially if it comes in a separate Xiangqi thema package,
> which doesn't bother the 99% of the users that don't even know what
> Xiangqi is. The reason of the current modest size is that I did not want
> to bloat the XBoard package with stuff almost no one uses.

What about making the board a composition of a plywood non-resized
texture in a single file, and resized SVG drawings on top ?


> > 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.
> >
> 
> Well, WinBoard has such a launcher (actually part of it), known as the
> Startup Dialog, where you can select engines from pull-down menus. I have
> always hated it, because I felt that these things should have been
> possible any time during a run. Which for engine-selection they now are.
> In combination with an -installTheme option having a theme-selection
> listbox in the View -> Board dialog seems the best option. I don't think
> it would be too difficult for the average manualophobic user to find it.

Sounds good


> > Right.  Maybe a more user-friendly message would be enough, and you
> > could keep the detailed reason for -debug ?
> >
> 
> Well, the reason for the user-unfrinedly message you saw now is basically
> that HaChu is non-compliant. It does announce the variants (and it should,
> because they are officially-defined and supported variants in the WinBoard
> Alien Edition, under which it can play them, or at least Dai and a
> crippled version of Tenjiku). But according to the standard version of
> XBoard they are non-standard, and so now interpreted as engine-defined
> variants. But the engine does not send a setup command for them when they
> get selected, so XBoard is really totally in the dark as to what these
> are. When I make HaChu send the setup commands (which would not hurt the
> Alien Edition, which would just ignore them, as there it is not an
> engine-defined variant), XBoard could give a more detailed error message.
> (Probably the setup command would define it as 15x15+0_dai, and since
> standard XBoard doesn't know Dai, the error I could let it print would be
> 'parent variant unknown, switching back to previous variant'.
> 
> Still not very elegant. Another solution would be to recognize all
> standard variants define in the Alien Edition protocol (checkers, go,
> reversi, amazons, dark, multi, alien, dai, tenjiku, dada, maka, tai), and
> ignore those, rather than thinking they are engine-defined variants. So no
> buttons would be created for them, and a user could not select them. Then
> at least you would not have these problems with engines that were
> originally intended for the Alien Edition (such as HaChu).

That would require updating xboard-compatible engines every time a new
variant gets added to the Alien Edition - quite ugly too :)

What about rather changing Alien Edition to recognize an alienvariants
feature instead, so it does not interfere with standard xboard ?