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

[h.g. muller]

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
functions.