[Freeciv-Dev] Re: switching tilesets at runtime (PR#1930)

[rf13@xxxxxxxxxxxxxxxxxxxxxx]

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 
> chance.

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".

        Raimar