[Freeciv-Dev] Re: switching tilesets at runtime (PR#1930)
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Fri, Aug 16, 2002 at 10:11:12AM -0700, jdorje@xxxxxxxxxxxxxxxxxxxxx wrote:
> The time has finally come...the client is, IMO, ready for a patch that
> will switch tilesets at runtime.
> The question is, how exactly should this work?
> First, here's a little background. The tileset switching patch will
> switch from one tileset to another, but it is not perfect. There is a
> strong possibility for memory leaks. Also, some graphics don't get
> updated propely - for instance in GTK the city dialog window doesn't get
> correctly resized (in other GUIs there are probably other issues). Both
> of these are acceptable, IMO, so long as the client pops up a dialog
> saying "This feature is experimental. You may have to restart the
> FreeCiv client for things to work properly." In time they will no doubt
> be fixed and the dialog will become unnecessary.
I have played with valgrind (http://developer.kde.org/~sewardj/) a bit
and I think it is the right tool for the task. So I will try to create
a patch for the "backend" ("just" a set_tileset fuinction) which has
minimal memory leaks. No idea when it will be ready and when I get
access to the net again.
> All of this can be handled cleanly by the addition of a new gui
> function, which is called at the end of a tileset switch. For now this
> function will pop up the dialog window; later it will do more
> complicated things like resize all open city dialog windows (or perhaps
> such resizing can be made automatic; I don't know).
> Up to here things are straightforward. But my question is, how should
> the user interface work? I see several possibilities.
> 1. Change the "default tileset" client option to just a "tileset"
> option. When the options dialog is closed, switch the tileset to the
> specified one (if it has been changed).
> 2. Same as above, but make the change immediately.
> 3. Leave the options dialog as it is, and add a separate interface for
> changing the tileset. I would implement this as a "tileset" submenu
> under the "view" menu, with a list of available tilesets in the submenu.
> Implementing #1 and #2 would require adding a callback function to the
> option structure: to be called in case the option is changed. This
> callback function would be called by the GUI when the option was changed
> in the option dialog, and would itself call the tileset update function.
> #1 is significantly easier than #2, since few changes would be needed
> to the current GUI implementations.
> Implementing #3 makes for a cleaner interface for changing the tileset,
> but requires more work on the GUI end and means that changing the
> tileset does not change the *default* tileset. This last seems like a
> major design flaw to me; on the other hand linking them is also tricky
> since the tileset can be changed with the -t option which currently
> doesn't affect the *default* tileset.
> As you can probably tell, I prefer #1. In any case, I'll put together a
> new patch with a demo interface that will switch tilesets when I get a
I would prefer #3 and an extra "Make current tileset default" menu
item which brings up a popup dialog: "Default tileset set to
foobar. Do you want to save the options now?" "Yes" or "Later".