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

[Yann Dirson]

On Sun, Feb 16, 2014 at 11:57:48PM +0100, h.g.muller wrote:
> Op Zo, 16 februari, 2014 12:53 pm schreef Yann Dirson:
> >
> > 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.
> >
> OK, that is very significant. Such dots are drawn on squares for which the
> corresponding element of a board-size array 'markers' is non-zero. Did you
> also see other such dots appear on other squares to indicate the moves of
> the piece you ppicked up, during the game? Normally it would clear the
> entire array 'markers' every time the user releases a piece on its
> destination square, and it should not be possible for a stray dot to
> survive that, no matter what caused it to appear in the first place.
> (Unless it would be caused by some out-of-bound access elsewhere, that
> happened again and again on every move.) Unless it would never draw the
> dots because the option is off, in which case it would also never erase
> them.

I could only see the dots for the pieces I selected prior to launching
two-engine mode.  If I attempt to select one while the engines are
playing, existing dots are removed, and (correctly) no new dot is
drawn.  Looks like it is just the list of dots that should be cleared
when an engine is assigned a side.


> > 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.
> >
> "xboard -fcp gnushogi", I presume. I will address the sizing problem.

Right :)


> > 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 ?
> 
> One reason for running XBoard for this is that the engine or theme package
> might not know where to find the XBoard data files, or even its .conf
> file. Their location depends on whether XBoard was installed from source
> or as binary package. Issuing XBoard as a command would by definition
> invoke the currently active XBoard.

OK.  OTOH, "make install" is also often run as root, and the less
stuff you run that way, the safer you get.

Calling xboard to request the paths to be used could be done at
configure time (typically *not* run as root), together with
substitutions to conf files if needed (although ~~/ probably makes it
unnecessary).

Then "make install" would just use those pre-specified paths.


> > It would also have the nice property that, when xboard ships a new
> > xboard.conf, it does not overwrite the previously-added themes.
> 
> Indeed, this is a problem I had not thought of yet. If themes are to be
> dropped as individual files, we might as well drop them in ~~/themes/conf,
> where the chu and shogi files are dropped now already. It would require
> XBoard to run through the contents of this directory in addition to
> reading its master settings file every time it is launched, however.

But then it would have to distinguish between those meant to be
specified through @preset and those to be unconditionally read.  And
since they are really confs, as opposed to presets, they are much
better located in /etc/.


> For engines we could do the same, in another directory. Actually I think
> this is a problem that transcends XBoard, as engines are also usable by
> other GUIs. There are plenty of GUIs that support XBoard protocol or UCI.
> So IMO there really is need for a standardized way for engines to announce
> themselves. E.g. in Debian the directory /usr/games/engines/cecp could be
> used for engines that support CECP, and /usr/games/engines/uci for engines
> that support UCI (and .../usi for Shogi engines that support USI, etc.)
> Engines could then drop a file there with some essential information, like
> the variant(s) they play, and the command for starting them, and perhaps
> some extra, protocol-specific info (like for CECP whether they use v1 or
> v2 of the protocol). All GUIs could then draw on that information, by
> looking in the directories for the protocols they support.

It's not that easy, as not all engine requires the same information.
However, I guess that could be done with little effort using the
debian "menu" framework - it is, however, specific to Debian and
derived distros, so it would probably count as "not generic enough".

The idea is that packages that need to announce themselves just drop a
file in /usr/share/menu, describing what they declare (eg. here
needs="XBoard"), and the various parameters.  On the other side,
consumer packages (for menus, that's window managers, taskbars and the
like, including an XDG backend generating .desktop files) provide a
kind of script that will generate their config file(s) from the
provided data.

In Omaha I have opted for .desktop files, describing plugins in a more
generic framework (also used to describe game, themes, etc).  But the
framework could be easily adapted to other formalisms (support for
Zillions rules are on my todo list, albeit near the end of it ;)

Best regards,
-- 
Yann