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.
