[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE[2]: New maintainer, plans for the future of XBoard

From: h . g . muller
Subject: RE[2]: New maintainer, plans for the future of XBoard
Date: Tue, 09 Nov 2021 11:07:22 +0000

Op di., nov. 9, 2021 om 01:07, Simon Scatton <simon.scatton@outlook.fr> schreef:

H.G.: do you want me to push your changes to the actual repo or will
you be able to recover your password and push them?

Well, let us first try to somehow revive my account on the git.sv.gnu.org machine.
I discovered that I still had another patch (in another git branch) that should be
added to the v4.9.x branch, and that I still have uncommitted changes in that
other branch (not existing on Savannah).

My developing activities were cut off abruptly because my desktop let me down
beginning this year: if I could boot it at all, it crashed with a blue screen after
a few times per hour. I solved that problem only recently.

The Janggi implementation should be more or less finished, though. I had created
a new branch for rewriting the code that handles probing the opening book,
presumably because it did not work well for Janggi (which is special amongst
chess variants in that it allows turn passing at any time). The current book code
is an absolute mess, which initially started as a simple hack. But then it turned
out to fail in many special situations, which were then fixed one by one by
adding more patches testing for these situations. The basic problem was that
XBoard does not keep track of the actual 'player state' the engines are in
(playing white, playing black or force mode). The gameMode variable only
keeps track of what state the engine should be in. But when using the book,
XBoard is selecting the book moves on behalf of the engine that has to play,
while the engine itself has to be put in force mode to feed it the book (and
opponent) moves. The problem is to recognize when the engine should leave
force mode (when it gets out of book) and receive a 'go' command. Keeping
track of true engine state at all times would make this conceptually simple,
but the current code does not do that.

As to the look of XBoard:

I will eagerly await the screenshots for the suggestions you have for this.
I am not sure what people mean when they say that XBoard looks obsolete.
The main window basically only shows a chess board and clocks.
Is it that people don't like pull-down menus? What some of the newer
commercial software uses instead of those (e.g. MS Paint) strikes me
as absolute garbage...

I often get the complaint that XBoard/WinBoard has a poor 'discoverability'.
There are many features that people apparently completely miss, because
they would rather die that read a manual or tutorial. This might be the most
important aspect that could be improved. Except that I am not sure how.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]