Complete.Org: Mailing Lists: Archives: freeciv-dev: April 1999:
Re: [Freeciv-Dev] Client options / Xaw and GTK code sharing
Home

Re: [Freeciv-Dev] Client options / Xaw and GTK code sharing

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: sune@xxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Client options / Xaw and GTK code sharing
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Fri, 23 Apr 1999 11:27:42 +1000

Sune Kirkeby wrote:

> I was looking into adding another clientside option, and found that
> the Xaw and GTK option dialogs share no code (or data), that I could
> find.  Would it not be easier to change the list of options in the
> future, if it was shared code?

Yes, the current Xaw and GTK clients still duplicate quite
a bit of code.  I think there are two likely things to do
to improve this (possibly complementary)

1. Extract out all possible gui-independent code and keep it
in the top-level client dir (this could involve some code
re-organisation, and I guess is what you are suggesting for
the options).

2. Write the planned gui abstraction layer; this would be similar
to above in that shared code is in client, and gui-specific
stuff in the gui dirs, but presumably the abstraction would
be at a lower level, with more shared client code calling 
gui-abstraction functions.

(Though the current priority is to release a version with
the GTK client, rather than cleaning up the code.)

> I was thinking something along the lines of
> 
>   struct client_option {
>     char *name,
>     char *description,  // for the popup dialog
>     void (*handler)(char *name, int selected);
>   };
>   struct client_option  options[] = {
>     { "solid_bg", "Solid unit background", default_option_handler },
>     { "wom", "Show Workers-on-map for new cities", default_option_handler },
>     ...
>   };
>   
>   void default_option_handler (char *name, int selected)
>   {
>       // this knows the mapping from names to global variables
>   }

Yes, something like that would seem good; but no C++ style 
comments please! ;-)

> Is support for options other than on/off (drop downs come
> to mind, as one)?

That could be useful, but of course more work to implement.

Regards,
-- David

[Prev in Thread] Current Thread [Next in Thread]