Re: [Freeciv-Dev] GTK

[Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxxxxxxxxx>]

On Wed, 18 Nov 1998, Mitch Davis wrote:

> Mirar wrote:
> > 
> > Is the GTK branch in CVS? I tried the GTK1.6 branch, but it doesn't
> > look GTK in any way.
> 
> The current GTK version is not in CVS.  Part of this is
> because the current GTK port doesn't have an abstraction
> layer, so there are two citydlg.c's, etc.  There is no
> easy way to have CVS accomodate this.

As Per said before, the source to the common GTK/Xaw client version is at:

<ftp://ulven.ifi.ntnu.no/pub/freeciv/fic-gamma2.tar.gz>

To install the client get freeciv-1.7.1.tar.gz from freeciv.org or the
above mentioned ftp site and:

1) gzip -dc freeciv-1.7.1.tar.gz | tar xfv -
2) rm -rf freeciv-1.7.1/client
3) gzip -dc fic-gamma2.tar.gz | tar xfv -

Build freeciv as usual.

* You need Gtk+ 1.1.2 and Imlib 1.8.1 at least to build the GTK+ client *

> I'd like to see the GTK port go out for 1.8, but I'm
> still undecided on how to cater for this in CVS, especially
> if there are two-of-everything.  (Sounds like Noah's ark..)

As is stands now the freeciv client has the following directories:

freeciv-1.7.1/client            * common (read: non GUI) code goes here.
freeciv-1.7.1/client/gui-gtk    * GTK+ related files go here.
freeciv-1.7.1/client/gui-xaw    * Xaw related files go here.

gui-gtk/ and gui-xaw/ have the code for the dialogs.  (i.e. you have
two-of-everything)

Of course there are (as always in life) several solutions(?) to this 
problem:

1) keep things as they are:
   * lowest coding effort in the short term.
   * painfull to maintain in the long term (and then again maybe not).
2) go for gtk+ only:
   * low coding effort in the short term.
   * easy to maintain in the long term (if gtk+ didn't change as much).
   * gtk+ is quite portable now.  It should(?) compile in the same
     OSes than xaw does.
   * would only delay the problem: what happens when we want a port for
     other non-X friendly OSes like Windows, MacOS, etc? Port GTK+? Yuck.
3) make a gui abstraction toolkit:
   * painfull, tedious effort being replicated by XXX folks out there.
   * would make client changes easy, but alas, the abstraction toolkit
     maintenance still would make a hit.
   * all client versions would look pretty much the same and would not 
     take advantage of the intrinsic toolkit strengths.

     Ex: i can't make weird buttons in other toolkits like the Gtk+ ones
       and their fancy use of widget subclassing.  Other toolkits seem to
       have buttons as two abstract classes: ButtonText and ButtonPixmap.
   * bad design of the abstraction toolkit could make ports to odd
     toolkits a nightmare.

   [3) would probably be the better option]

    Remember this: the code in the client is heavily (80%?) toolkit
  dependent.
    Most non-GUI code is in the server, and not in the client.

> If the abstraction layer were in place, then it would be
> substantially easier:  Only one citydlg.c, etc, which
> can be in the same place as the current one, and some
> additional libraries which do the concrete work according
> to the desired windowing system.

Yup, that's right.  Now if someone would volunteer to do that i would
shake his/her hand (don't have time for such heavy coding until Xmas).

BTW, when will be released 1.7.2, so i can start work on the client port
for that?  (I know timing release dates at this point is difficult)

-Vasco

---
Vasco Alexandre da Silva Costa, student @ Instituto Superior Tecnico,
Technical University of Lisbon - Software & Computer Engineering