[crossfire] GTK V2 client default layout and map size

[Kevin R. Bulgrien]

>   So I played around a little bit last night with making the map deal with
> size requests properly.
>
> Just to play around, I made two minor changes:  In the glade layout file
> (in this case, I used the gtk-v2 glade file), I removed the size
> specification in the drawingarea_map widget.
>
>   In the gtk-v2/src/map.c file, I removed the gtk_widget_set_size_request()
> on the drawingarea.
>
>   Both of those seem critical, as without them, they set what seems to be
> the minimum size the drawingarea can be, and won't let me resize it smaller
> (I can move the viewpanes, but the window stays the same size and it
> doesn't generate any configure requests).

Remember that the .glade file has size requests for the map drawingarea. I
have been playing with removing the size requests in the glade file (without
looking much at the code) to try to make sizing more flexible, but have had a
lot of trouble with other issues when I did that.  Maybe some solution
involves both code and the glade file.

>   Now one might thing that isn't that big a deal - it will figure out the
> right layout on its own.  Unfortunately, this is not the case, and glade
> does some whacky things - see:
>
> http://tavern.santa-clara.ca.us/cf/gtk-v2-layout.png

Yes, I've seen stuff like that even just playing with the .glade files.
I have not figured out all what is going on.  There are shrink and resize
properties for some widgets that seem important, but I don't yet know
enough how to correct some of the problems.  Some things can even render
the position settings on the *panes completely ineffective as you say
below.

>   This in spite of the fact that the map area and stat vpane is set with
> specific placement.  And what I find even odder is that it screws up the
> inventory area - this seems like an effort on glade to try and align
> things.  If I put the size specification back in the glade file (but still
> have that code change), it puts things in the right place.
>
>   Also, if I go and move the panes around into the right spot, and then
> save off the window position, next time I run the client, things are in the
> right place.
>
>   Now these placements seem to be an issue related to glade, and probably
> not something we can solve mucking in my code.
>
>   But my thought is this - since saved window placements work out fine,
> what about including default window placements as part of SVN?

I have considered this a bit, but did not think about it as much as you
have.  You may be on to something.

>   When the client runs, it can look for these placements in the normal
> install area if it doesn't fine a user customized one (if it finds a user
> customized one in their homedir, it ignores that global one).  This fixes
> any odd placement issues, and I think will actually make the glade stuff a
> bit more morphable, as I suspect a fair number of layouts may have various
> size settings for things to 'look' right, which may not be quite the right
> thing.
>
>   Another thought related to this is that I could also perhaps see
> different versions of these window positions for different resolutions.
>
>   For example, a new user running on a laptop with a 1440x900 resolution
> screen fires up the client.  The client can do a pretty simple query to see
> what the resolution is.  It decides the layout.1280x1024 isn't good (won't
> all fit on the screen), but that layout.1024x768 does, so it uses that.
>
>   A user running on an old laptop (800x600) has it use the layout that
> actually works right on that size.
>
>   Making all these different resolutions files would be a pain, and
> probably only really necessary for whatever is the default layout.  But
> there is no reason that these layout files should be any different than the
> .pos files saved in the .crossfire directory, so would be very easy for
> users to contribute them (in that 1440x900 case, the user might say 'here
> is the layout I use for this resolution')

It's worth thinking about, though at some consideration, it seems quite
noisy/messy to store individual files as the sources, though admittedly,
likely very easy to implement (which is a lot of why I went with name.pos
in .crossfire).  I'd think one could have a .pos converter that could
roll this data into a single file where one could have some meta-data
could more easily be used than having layout sizes in the file name.
The .pos file could be simply "contain" by some markup because it is a
consistent format.  A reverse tool would spit out the equivalent file
when it was selected.

Dunno.  Random thoughts.  Real Life is encroaching hard right now, but
wanted to respond as I've been messing in this area lately.

Kevin