[crossfire] GTKv2 trunk client to branches/1.x client (was Release 1.12)

[Kevin Bulgrien]

> > Why don't people get that you can build GTK-V1 with GTK2?  This is the only
> > way the Windows client is built.  I don't think it should be dropped until
> > jxclient is released.  If anything, change the default build to use GTK2.
> 
> Just from a support/maintenance standpoint, I'd be in favor of getting rid of 
> the gtk client.
> 
> The main reason it has been around so long is because folks didn't really like 
> the layout of the gtk2 client.  But with the different layout options, that is 
> really all fixed - I can't really think of a compelling reason why the gtk1 
> client should be retained any longer.

All I'm saying is there is no Windows to release if GTK-V1 is gone, though I do
suppose that keeping it around for Windows does not mean you have to keep it
around for *nix.
 
> > I wholeheartedly agree, but we need to be sure mwedel's changes are completed
> > or we release prior to that change.  His check in comment said that server
> > changes need to be made to avoid horking up the display.  Further, he changed
> > only the GTK-V2 layout and not all the other layout files for the resizing
> > thing he did.
> 
> The other layouts should get updated - I didn't even think about that.
> 
> With unmodifed layout files, things should work just as good as they did 
> before.  Which is you won't be able to resize the map window, so those changes > I made just won't get used.
>
> Testing with the other layouts would likely need to get done.  The reason the 
> size for the map window was removed was that it acted as a minimum size (or so
> I seem to recall).  That said, without a size parameter, it may default to a
> not very useful layout.

Yes, the whole minimum size thing has always been a beef, and I've tried a few
things to fix it, but never found a solution that works straight out of the
XML file.  Frankly I think glade designer is somewhat broken in that it lets
you lay everything out to a certain size, but then does not program the sizes
in as soft defaults.  This is what made the GTK-V2 client so objectionable when
all I had were 17" monitors around.  And yes, if you do not have a windows
position file saved yet, without it, the UI is a mess.

While its not an ideal solution, I did think of either hardcoding a minumum
default size if a window position file doesn't exist and/or having a small data
file that sets certain defaults for the window size.

>   I already have the server changes - they are fairly trivial - I'm just not 
> sure if they will have bad effects with other clients.  The change is basically 
> that whenever the server gets a new map size, it clears all its cache and thus 
> resends the entire map to the client.  What I'm not sure is if other clients 
> actually will change the mapsize after play starts, and if clearing that data 
> would give a result they don't want (it sort of has a bad side effect on the 
> client in that it will also clear all fog of war information).
> 
>   My belief is that the resizing of the map window is really something a player 
> will do to get the desired layout they want, and not something will be 
> constantly playing with.

Agreed.  And the initial sizing being a bit wonky at first isn't a crisis when
you have no prior window position save file,  but the initial sizes should be
reasonable, and I do not think they are at all reasonable (at this time) with
those sizes removed from the XML file.

> > By the way, I'm also ok with thinning the number of offered layouts in a
> > default install might be wise.  Perhaps we could pack up the others by
> > adding a package for extra layouts.  If we do something like that, we
> > probably need to try to test the water and see what people think about
> > the various layouts, though I'd tend to package the layouts that work
> > for lower screen resolutions with the client... which reminds me I still
> > haven't checked in that 640x480 layout.
> 
> My only issue with a bunch of different layouts is potential support issues - 
> if one is rendered oddly and bugs are filed, if it is a standard layout, that 
> sort of suggests it is something we should fix.

I guess thats part of the point of suggesting a smaller layout set as a standard
set, but, it does not seem unreasonable to me to have two or three alternate
layouts in the standard set that aren't too similar...  The one I still have
not checked in is quite radically different in its control set than the
others, and is probably worth considering for that very reason.  There's not
much point to providing multiple layouts that just change the position of stuff.

There is more than one theme supported.  Now granted, a theme is far smaller to
package than a huge XML file, but it is probably no less, if not harder, to
tweak themes, based on my five minute review of a theme file, so I guess a bit
of a precedent has already been set to ship the client with more than one
option.

> I'm not sure if we could do some form of unsupported or contrib layouts - 
> basically, we make these available, but use at your own risk and we don't offer 
> any support for them.

Maintenance on these files is hardly difficult once you get them working.  Still,
an alternate layouts package could certainly take a lower priority for sure,
though I think "use at your own risk" and "don't offer any support for them" begs
the question of why we even bother to package them then.

I plan to be around a while, even if I drop out of the picture for a few months
now and then.  I'm perfectly fine with taking the responsibility for the XML
files.  I think they add something to the client that is worth keeping.  Even I
switch out now and then to see what "fits" me best.  I don't see a compelling
reason to take that away from a player at this time.

Kevin