[Top][All Lists]

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

Re: [XBoard-devel] XBoard -- 'Study game' mode and GTK.

From: h.g. muller
Subject: Re: [XBoard-devel] XBoard -- 'Study game' mode and GTK.
Date: Wed, 11 Jul 2012 11:11:20 +0200

On Tue, Jul 10, 2012 at 7:19 AM, S. A. Albert <address@hidden> wrote:
What is it: it is a kind of 'edit game' where all plies (moves) are stored
(accumulated) in a tree of plies and a cursor could be moved to some node of
the tree to decide which position is displayed. The tree of plies is displayed
in a specific X11 window (similar to the history of moves window) with the
cursor highlighted. The tree of plies could be saved apart from the original
PGN game file. When a newer PGN file of the game is downloaded, the tree of
plies can be reloaded and edited again.

Well, XBoard already supports variation trees, (walking them, or entering new variations).
It does not store them separately, but in the PGN itself (as recursive variations).
I think this is the superior method; PGN format was designed to do that.
So the only thing new in your proposal is the way to display the tree. Currently there
is only the Move History window, and it only displays the current branch of the
tree-walking process.

Rather than adding a new window, I would prefer to just  alter the format of display
in the Move History window. We already have so many windows, and the window
you propose would have a purpose that overlaps very much with the existing one
(namely quickly navigate through the game or tree). A better display of variations
there has been (somewhere low down) on my wish list anyway.

So my counter-proposal is to find a better way to format the Move History window,
and include variations in there. I could imagine the user would want to control this
through some settings, as always displaying the full tree would probably be too much.
Perhaps the tree could be organized similar to a tree widget? E.g. there could be
a special symbol (like {*}) after each move for which the PGN contains a variation.
Clicking on that symbol would then 'open' those variations, i.e. show them on separate
lines with appropriate indentation before continuing with the main line. These variations
would then again contain {+} when they have embedded sub-variations, on which you
could again click to open those, etc. Before every variation line there should probably
be another symbol (e.g. {-}) that you could click to collapse it again.
Global settings could control the number of nested variations that is expanded in the
display by default. They could also control whether you would see any levels above
the one you have currently 'promoted' to main line (and how many).
I have little idea of what would work best, as I never do this kind of stuff. Which is
one of the reasons a tree-view mode is not yet implemented.

A patch like that does not seem to need any front-end support. It would be purely back-end.
So it would be immaterial in which port it was made (X11, GTK, WinBoard).

I cloned the git repository to analyze the source-code in order to find how I
could implement the 'study game' mode.

(1) Is there some Doxygen make setting so I can browse the source-code
data-structures and functions ?

No idea. (The level of my *nix knowledge is such that I even have no idea what you are
talking about. Arun was responsible for all the make stuff, I just know how to type 'make'.)
I was wondering for which -- X11 and/or GTK -- front-end it's better to
implement the 'study game' mode depending on current status of GTK port and
future maintenance of the X11 front-end.

(2) Which is the GTK port state ?

Not finished, but close. Problem is that it is probably not entirely up-to-date with the
latest back-end changes as well. It has been a long time since it was rebased on master.
(3) Will the X11 front-end be maintained when the GTK port is stable ?

This is not clear. No one is currently working on GTK, and X11 is the only thing I know
how to do besides WinBoard. I have recently completely reorganized the X11 front end,
shrinking the amount of X11 code in it to a bare minimum, and isolating it well from the
rest. So the current master-branch code consists of 4 parts:
1) What was historically called back-end, shared between XBoard and WinBoard
2) Platform-independent front-end, which logically belongs in the back-end, but is not
   used in WinBoard (or the GTK port), which sort of duplicate the code in their front-ends.
3) *nix-specific code, that would be sharable by any port to Unix-based platforms (OSX,
     Android, GTK). Mainly stuff like pipes and starting processes, using sockets etc.
4) Pure X11 code.

This as a preparation for making an Android port of XBoard, which would then only have
to replace (4), which is now very little code.

This would mean (1), (2) and (3) should continue to be maintained in any case, as the
Android port would need them. (4) is now designed to be so general that it would not
need any (or hardly any) maintanance. (Adding new menu items dialog controls or
even entirely new dialogs, for example, would only touch (2), and not require any
code changes in (4).)
I might give a help for the GTK port, if needed. Please, let me know.

(4) Which branch should I 'git checkout' into ('gtk' or 'gtk-xt') to build the
current GKT port ?

gtk-xt. I think the other gtk branch is quite obsolete. The Xt component is now fully
deleted from the gtk-xt branch, in the process of gradual replacement. (IIRC)
Currently no one is maintaing the GTK branch, however, so it has again acumulated
a sizable lag compared to the X11 and WinBoard versions in master (and even v4.6.x?).
(5) What is the correct contributing process (for the 'study game' mode) ?

We have no formal 'contributing pocess'. Sometimes people submit patches, and we
incorporate those in the main line. For something as big as what you propose it would
be good to have some advance coordination on the design, so that we can be sure
we want it in the main line, and that it will not interfere with other existing or planned

reply via email to

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