[XBoard-devel] GTK progress

[h.g. muller]

Time to give a summary of what I have done the past week:

I took the GenericPopUpGTK routine in the gtk-xt branch, which was
written by John Cheetham, and extended its capabilities, so that it
was able to also generate listboxes, pull-down menus and drawing areas.
Then I took all X11 code out of the master branch (after the cairo port,
so that all drawing was already handled outside X11), and put in this
GenericPopUp, and other parts of gtk-xt code that could act as direct
replacement of X11 code in the master branch. (E.g. code for copy
and paste, the code for various timers and dispatching of pipe and socket
input events.) I put all that code in master, and supplemented it with
newly written gtk code where no equivalent was available.

This produced a gtk version of the latest XBoard master that sort-of works.
The sources are currently in the gtk2 branch of my repository at
hgm.nubati.net. The job is still not completely finished; in some places
there is some Xt/Xaw code preserved, disabled by #ifdef TODO_GTK
directives, which I did not replace by a GTK equivalent. Often because
it was not clear whether such an equivalent is in fact still needed, but also
where I simply did not know how to do it.

The GTK front-end has been reduced to the 4 *.c files (xboard.c, xoptions.c,
xengineoutput.c, xtimer.c) and 2 *.h files (xboard.h and xengineoutput.h).
These have been moved to a new directory 'gtk' in the source tree, so they
can in principle co-exist with the old X11 front-end source. The idea is that
the front-end is now so small and general, that future enhancement of
XBoard functionality will not need to touch it at all, so that there is no
real penalty on maintaining several front-ends in parallel. The code base
is now organized such that we basically have 3 'ends': the old back-end,
shared by all ports, including WinBoard; a 'middle-end', consisting of
platform-independent code shared by the X11 and GTK front-end
(and possibly by other front-ends in the future); and widget-set-dependent
code in the true front-ends. Virtually all drawing has been moved to files
that are independent of the widget set, and just use cairo. Code that
does not interact with the GUI, but is nevertheless OS dependent
(fork and pipe stuff) has been concentrated into a separate file usystem.c,
for easy replacement in case of an OS with a non-Unix-like API.

Implementing the GTK version in a decent way required me to make
some minor changes to the 'middle-end', so that it will not work with
the old X11 front-end anymore. (This mostly concerns diversifying
Option types that in X11 were represented by the same widget type
into different types, where GTK needs different widgets for those.
E.g. Label and Icon, where in X11 icons are drawn in labelWidgets.)
My intention is now to adapt the X11 front-end so that it compiles
again with the middle-end from the gtk2 branch, and then merge
gtk2 with master (perhaps moving the X11 front-end files to a directory
xaw). We can then release a version that can be both compiled for
the traditional X11 front-end, as well as for a (more experimental)
GTK version.

As to the current status of gtk2:

There are some things that are not yet implemented, and some things
that work, but in a suspect way. In the former class we have

*) Key binding. I am not sure if GTK has a global mechanism for that,
like the .Xresources in X11, which we have to respet, or whether I should
simply hard-code it in the key-press-event handler.
*) Repositioning and resizing of windows based on saved settings.
It is not sufficiently clear to me how this should work in GTK.
*) Raise window, and focus transfer. (This might be automatic in
most cases in GTK anyway.)
*) Setting of the text on the task-bar icon (not sure if this is possible
at all in GTK, or that it is a privilege of the window manager).
*) Everything that has to do with fonts
*) PopUp menus. (These are all deprecated anyway.)
*) line gap and clock widgets are not adjusted in manual sizing
*) the engine logos don't display in a correct layout yet.

Suspect things:
*) Animation seems to be very tricky in GTK. The way XBoard does it,
with a usleep call in a loop, blocks the GTK main loop, and reliable
rendering seems to be dependent on that. As a result, expose events
and drawing somehow get out of phase, so that the newly drawn animated
piece is only partially shown.
  I managed to get it working, but only by critical tuning of the number of
software-triggered expose events (= drawing the memory buffer onto the
widget with a gdk_draw call). Too many of those cause clipping of the
animated piece when the animation frames overlap, too few cause the
piece to disappear entirely in case the animation frames do not overlap.
  This suggest that correct operation of the current code is critically
dependent on the implementation of drawing in GTK. Which of course
is very undesirable.
  Switching off double buffering does not seem to have any effect.
Ordering main-loop iterations from the animation loop breaks XBoard,
as it will also process input events from the engine before animation
is finished. And the correctness of the code is based on the assumption
that the handling of moves is atomic.

*) Window sizing. leaving sizing of the main window entirely to GTK
add unwanted filler space below the board. It is not clear why, but it
seems bent on respecting a 25-pixel bottom margin. So to get a decent
layout I have to resize after initial popup to take out those 25 pixels.
And to get manual resizing working I have to rely on that same assumption,
that the height the window needs on top of the board size is 25 pixels
less than what it actually was after popup, and calculate the new square
size baed on that.