Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2003:
[Freeciv-Dev] (PR#5141) "Next time open" not persistent
Home

[Freeciv-Dev] (PR#5141) "Next time open" not persistent

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] (PR#5141) "Next time open" not persistent
From: "John Wheeler" <jdwheeler42@xxxxxxxxx>
Date: Sun, 21 Sep 2003 04:45:09 -0700
Reply-to: rt@xxxxxxxxxxxxxx

[jdorje - Mon Sep  1 18:27:18 2003]:

> [jdorje - Wed Aug 27 19:20:46 2003]:
> 
> > [jdwheeler42 - Tue Aug 19 18:15:40 2003]:
> > 
> > > In the city dialog, under the "Settings" tab, the "Next time open"
> > > setting is not saved in .civclientrc, so every time the client is
> > > restarted, it reverts to the default "Overview" setting.  (If
> > > accelerators for the tabs were restored in CVS, this wouldn't be as
> > > important.)
> > 
> > This is not easily solvable since the .civclientrc data is saved by the
> > common client code, but the city dialog pages are gui-specific.
> 
> OK, it's worse than this.  The data is put into the savegame so it is
> persistent on a per-city basis.  This of course means it must be sent
> to the server.  But all this is done by the GUI code, so there's no
> guarantee whatsoever that any of it will be consistent between
> clients.
> 
> In other words switching clients will probably give garbage for every
> city option.  Some of these options are not to be trifled with...

I think conceptually what needs to be done is have all the integer
values for GUI options in a common enumeration, so every value is
unique.  Then, like with HTML browsers, clients can ignore options they
don't understand.

That said, now that the accelerators are restored in CVS for GTK2,
disband and rename are the only things I use on the settings page.  I
leave all the auto-attack settings checked, even though I've never
actually seen auto-attack work for me.  The "new citizens" setting is no
longer useful to me; the CMA takes care of that now.

But even if all the current settings are removed, I think the enumerated
list for options should still be used, because I can easily see adding
more settings in the future.  (And of course, once the common enum is in
place, values should never be removed from it, so defunct options will
be safely ignored.)

-- 

++JohnWheeler


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