[XBoard-devel] (no subject)

[h . g . muller]

Op Wo, 27 februari, 2013 7:55 pm schreef Arun Persaud:
>> This does seem a pretty serious bug (for those that have X-servers that
>>  have this bug). Does it warrant quick release of a 4.7.1? Or should we
>>  perhaps wait until all translations are in, and do a 4.7.1 then? Or
>> perhaps try to do some more fixing of the GTK build on the side?
>
> Up to you. I could wait a bit with 4.7.1 and wouldn't mind getting some
> more new features in at the same time.

Well, I guess that the need for a 4.7.1 has increased a little, as someone
reported a bug in the Analyze Game function batch mode. It turns out this
mode in general does not save the games it annotates, which was the sole
reason for its existence. I missed that when testing, because the saving
is dependent on the presence of a 'result comment', and I had only been
analyzing games where the analyzing engine could see the game had finished
(mate or 3-fold rep), and would provide the applicable result comment. But
on human games, which in general end in resign or draw by agreement, it
never saved them.

In addition there were a few annoying incompatibilities between the WB
protocol extensions used in the Alien Edition, and standard WB protocol
used in 4.7.0, making it impossible to run engines designed for the Alien
Edition to fully work under regular WinBoard even in variants the latter
did support. Although not strictly a bug, it seemed better to fix that as
well.

What 'new features' did you have in mind? Normally we would not do any
bigger things within a stable branch, out of fear of jeopardizing the
stability. I have some ideas, but they are mostly major stuff:

*) Rework the back-end code, to make tests on variant disappear in favor
of tests on individual game characteristics (e.g. not test for shatranj,
but test general-purpose rule flags that tell whether double Pawn pushing
is allowed or all promotions are to Ferz, etc.). This to make it easier
for engines to tailor the behavior of the GUI to the need of non-standard
variants.
*) Port the 'highlight feature' from the Alien Edition to the regular
version (and to XBoard). This feature allows the engine to perform the
'show target squares' function, which XBoard cannot do if legality testing
is off, and pieces might not move as XBoard thinks they do. A protocol
extension informs the engine when the user grabs or releases pieces, and
the engine can reply with a highlight command containing a 'color-FEN' to
indicate where marker dots should appear. This also makes it possible to
do legality testing in the GUI for games with unknown rules: it can only
accept releases of the piece on the squaes the engine marked. This can be
elaborated on by assigning different functions to different color that
XBoard will be aware of: squares the 'lifted' piece could promote on can
be marked with a special 'promotion color', and when the user puts down
the piece on such a square, this could be a reason for XBoard to show the
promotion popup (or activate sweep selection of the promotion piece), even
if the square would not ly in what it normally thinks is the promotion
zone.
*) Allow the use of a referee engine, possibly connected as third engine.
With legality testing off WinBoard would rely on this referee engine for
determining move legality and result-claims.
*) A somewhat more modest feature would be to improve the Eval Graph. Some
people like to have a derivative-mode there, where it does not show the
absolute score, but the amount that the score changed by the previous move
(so that blunders show up as spikes). This could be provided as an
alternative view. (Not sure what would be the best method for the user to
switch views, though. A right-click?) The Eval Graph also has a 'zoom'
function, expanding the score range [-1, 1], which can be set in some
dialog (and for WinBoard, only through a command-line option). Perhaps the
mouse wheel could be used to modify this zoom factor when the pointer is
in the Eval Graph window.
*) Finally we could do themes for XBoard. WinBoard now has a Themes dialog
that people seem to like; it stores the theme settings in the settings
file in a way similar to the list of installed engines, and allows the
user to define his own themes. It would be trivial to port this dialog and
treatment of themes to XBoard.