Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2004:
[Freeciv-Dev] Re: (PR#7079) Remove unneeded options from clients
Home

[Freeciv-Dev] Re: (PR#7079) Remove unneeded options from clients

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jordi@xxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#7079) Remove unneeded options from clients
From: "Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>
Date: Thu, 15 Jan 2004 21:33:00 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7079 >

On Thu, 15 Jan 2004, Jason Short wrote:

>
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7079 >
>
> > [mkirzinger - Fri Dec 12 21:10:33 2003]:
>
> > One way this could be done is to add a int inside the client_option
> > struct which identifies what clients the option is for.  Each client
> > could be assigned a bit in the int.  If it is set, the option applies to
> > that client, if not, the client can ignore it.
>
> I would rather do it a different way:
>
> Have a separate array gui_options declared by each GUI.  At runtime this
> array is appended to the options[] array.
>
> The advantage of doing this is that GUI-specific code (the bitfield
> enumeration) doesn't get put into the core client code.  New clients can
> be added or removed without having to change this code.
>
> One thing to worry about is that clients will overwrite each other's
> options.  If the options have the same name this is unavoidable.  But if
> they have different names they should still be saved (even though they
> are never loaded).  I'm not sure how section files work in this regard
> but I suspect this overwriting is unavoidable (and acceptable IMO).
>
> Will you change your patch to do it this way?

Client specific options should have a special prefix in the name to
prevent name conflicts. For e.g.: 'gtk-2.0-foo'.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa






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