Re: [XBoard-devel] Xboard GTK on Windows

[h.g. muller]

> HGM: can you already give a list of windows that are ok to port (apart
> from the filebrowser)?

Is that apart from the main window? (I am not very happy with the
separation there either, in particular drawing the board (DrawPosition)
is now completely in the front-end, while I think only the primitives
like "draw piece P at coordinates (x,y)" should be there. But I am not
sure if it would pay to change that.)

A problem is that we have to make a few design decisions first:

1) Move-History window: XBoard has a list-based window for this,
with columns for black and white moves, while WinBoard displays
the game in a free-format text field. The latter can also include the
depth/score info in {braces}. If we look at competing GUIs, the
WinBoard format is the more common. Unlike all other windows,
the XBoard format of display is 'Giraffe portrait', making it very hard
to have a sensible tiling of the windows. The WinBoard format would
also make it easier to display variation trees in an organized way
(using indents etc.), if we would want to do that in the future.
  So I would say we redesign it in WinBoard fashion. This, however,
means that the front-end part will completely disappear, as it can
be handled by the generic popup through a normal text field.
So in that case (but only in that case) there is nothing to port,
except for a click-to-character-position callback, which is needed
in several other windows as well (Comment and Engine Output).
The rest is all back-end code, which I can steal from WinBoard.

2) Game-List Options dialog: I implemented this as an almost
exact copy of the WinBoard dialog, which is list-based, with
buttons to let the user do a kind of bubble sort on the list
containing all possible tags, pushing those you don't want
displayed under a line. This is a bit of a pain, because it is
unlike any other dialog.
  An alternative design would be to use a pull-down menu that
contains all tags, and a multi-line text widget that adds any
tags you selected (and perhaps a button to clear it). Just like
the participants selection in the Match Options dialog works.
This means a complete re-write of the back-end part (but this
is basically only translating the string with single-letter tag
codes to the full linefeed-separated tag names back and forth),
while the front-end would completely disppear. (Assuming the
generic routine to add a line to a text edit is already ported
on behalf of other dialogs.)

The following is an overview of all windows that XBoard has, and their status.

Generic popup           Ready to port
Game List               Ready to port
Game-List Options       see above
Evaluation Graph        Ready to port
Move History            see above
Engine Output           Slight enhancement of the Generic popup could make 
it disappear
New Shuffle Game        Should be made to disappear
Time Control            Ready to port (redesign in the process?)

The Time Control dialog should probably be redesigned to use the radio buttons
to enable or disable text fields for the entry of movesPerSession and 
timeIncrement
which are always present (and dedicated to that parameter), rather than
having them re-assign text edits to different parameters (changing the text 
labels
on them), as is done now. (Mea Culpa...) This is probably best done by 
designing
it from scratch as an individual dialog, as I understand this is easy in GTK.

The Engine-Output window does not contain any special elements, but it requires
a control over their layout that is currently not provided by the generic 
popup.
(In particular that the panes are above each other rather than side by side,
and many label widgets on a single line.) This could be solved by adding 
just a few
if statements in the Generic popup, though. (That already knows a 'Break' 
option type,
and a bit in one of the (now unused) parameter fields could be used to indicate
the next pane should be positioned vertically w.r.t. the previous one, 
rather than
horizontally, and a similar bit on a Label option could specify the reverse.)
I am not sure what would be the easiest solution here: make these small
enhancements in the generic popup, so that the front-end part of the Engine 
Output
could entirely disappear, or design Engine Output as an individual 
dedicated dialog.
But I guess even when we port the generic popup as it is now, we could always
add the small enhancements afterwards. (In fact I could already do a re-write
of the Engine Output with the genericpopup without these enhancements
that is fully functional, but has an impractical layout. But it is probably 
better
to postpone the decision untill we have some more experience with other
dialogs.)

Anyway, the most crucial thing to port is the generic popup (the lower half
of xoptions.c), because it is the front-end to so many dialogs (new variant,
load engine, common engine settings, engine #N settings, board, sound,
general, load, save, match and ICS options, adjudications, comment and
tags popups, new shuffle game). The first target should be to get the
Engine #1 Settings for fairymax and glaurung right. Then all those other
dialogs will automatically work as well.