[Freeciv-Dev] GTK+ client and GTKstep

[Daniel Burrows <Daniel_Burrows@xxxxxxxxx>]

  Hello again..I have a real problem this time. :)

  I just got my hands on the latest GTKstep theme.  This version includes a
number of enhancements, including (finally!) the ability to move scrollbar
arrows to the bottom and left of scrollbars and to move the scrollbars
themselves to the bottom and left of windows.  The only problem?  It doesn't
work.  :-/

  Here's the situation: there exists a GTK+ widget called the "scrolled
window".  This widget is a container which can hold another widget and allow
it to be scrolled around.  Unfortunately I'm not very well-informed on the
details of how the scrolled window works, but I believe that it allows a widget
to 'think' that it has a larger space to draw in than it does.  The GTKstep
engine appears (I haven't checked this) to operate by somehow altering the
GtkScrolledWindow so that it places its vertical scrollbar on the left-hand
side of the window.  Several other widgets also can contain internal scrolled
windows; these appear to work correctly.

  The problem with this is that, perhaps due to limitations of the
GtkScrolledWindow (eg, I'm not sure you can use it easily if you want to
handle scroll events yourself??), it is all too common for GTK+ programmers
to create their own scrolled windows by packing the scrolled widget into a
box with the scrollbar.  There is no way for the Step theme to detect this
arrangement (standalone scrollbars are more often found in places such as the
Tax Rate dialog of Freeciv) and so it does not move them.  The result is a
rather unpleasant-looking mishmash, in which some scrollbars are correctly
positioned and others are in their original places -- worse, this makes the
NeXT-style placement of arrow buttons *less* useful since it increases rather
than decreases the distance between them.

  Freeciv has two obvious places where the scrollbars are not handled
"properly", both in the first thing the player sees:

  -> The main map window
  -> The text underneath it

  After poking around a little, I discovered that the map window seems to
handle its own scrolling in a way that would indeed make it difficult to use
a GtkScrolledWindow.  I haven't looked into the text area.  The metaserver
window uses a CList and seems to work correctly, as does the simple GtkList
in the city change-production dialog; I haven't gotten scrollbars to appear
on the city report window or the message window, so I don't know about these
(but I suspect that they handle them properly).

  I think that perhaps the most general way to handle this problem is to make
the map into a proper widget.  As I understand matters, we would handle Expose
events to draw the part of the map which was exposed and report our size as
being the total map size.  We would then pack this widget into a scrolled
window, which would control the visible area and only send Expose messages for
the visible part of the window (thus handling the potential problem of losing
efficiency by drawing more stuff than we can see)  I would propose that, if
this method is used, the map window be "dumb" -- that is, it would only handle
the graphical representation of a map; the game logic would have to tell it
what the map was, when terrain changed, what units were present, etc, and the
only response it would have to events would be to fire "player clicked on tile
X" or "up key pressed" signals.  The reason is that this encapsulation would
allow it to be easily reused for the map editor, the city dialog, and perhaps
other places as well. (use your imagination :) )  -- one cool idea is to allow
multiple maps to be open at once, although this would require a little footwork
in the game engine.  A proper map widget would make this easier.

  I've never actually written a GTK+ widget but I've read the documentation on
how to do it and used the toolkit extensively.  If there are no objections
(heck, even if there are :) ) I'd like to start working on a GtkFreecivMap
widget with an interface To Be Determined Later Today.  I think the benefits
(aesthetic and otherwise :) ) are significant enough that this would be a Good
Thing[tm].

  One other note: when using the GtkStep engine, I see two anomalies in the
city window: first, there appear to be random patterns of dots in the blank
slots of the citizen list (upper-left).  Second, there blank slots of the
'units present' list are dark gray rectangles.  (these may be bugs in the engine
itself, I don't know..)  In addition, redrawing of the city dialog appears to
be rather slow, but I'm not sure if this is related to the engine at all.

  Daniel

-- 
There are many of us in this old world of ours who hold that things break
about even for all of us.  I have observed, for example, that we all get
about the same amount of ice.  The rich get it in the summer and the poor
get it in the winter.
                -- Bat Masterson