Re: XBoard -- 'Study game' mode and GTK.

>On Tue, Jul 10, 2012 at 7:19 AM, S. A. Albert 
><<mailto:[email protected]>stephane.alexandre.albert@gmai 
>l.com> 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.