[crossfire] GTK V2 client default layout and map size

[Mark Wedel]

Kevin R. Bulgrien wrote:
>>   Quick thoughts/past notes:
>>
>>   I expect that the preferences will be driven a lot by what actual
>> hardware folks are running on.
>>
>>   If you only have a display that does 1024x768, then the Oroboros is the
>> likely winner.  But if you have a higher res display, that probably isn't a
>> first choice, as you have a lot more display area than it uses.
> 
> I'm not bothered by that, and it actually is in the spirit of making the
> game more accessible anyway.  I'd consider setting it as the default
> without even taking a vote.  Why should not the majority get their
> choice anyway - even if it isn't your or my favorite?

  I have no problem with the majority not deciding the default layout.

  My point is that the majority is more likely to vote on what works best for 
them.  If the majority chooses a layout that doesn't work good at low 
resolutions, is that the final word, or should we try to do work that makes 
things work better for low resolutions?  Hard to say what the right answer is 
(at one time, a fullscreen mode was suggested, but with the wildly varying 
screen resolutions, that would be really hard)


> Then... there is the whole thing about making the map size coincide with
> a selected layout...  Right now it is difficult to know what to set the
> map size too.  A first effort to address that is probably due quite high
> priority.  You can totally hose a layout by using 25x25, which is the
> current default.  I think the default map size should be a low common
> denominator unless new features are added to hint map size settings.

  That should really get improved - arguably that is a bug going all the way 
back to the original X11 client.  What should really determine the mapsize is 
the size of the window pane provided for it, not what is set elsewhere.

  That is also just a lot more user friendly.  Start with a small map size and 
resize?  You get a larger map display.  Resize smaller?  It should reduce the 
map size.

  I need to look and see how hard it is to do that.  One issue with that plan is 
there could be folks that want a relatively  little map data (11x11) sent from 
the server, but still have a larger viewable area for fog of war.  For folks on 
highly constrained bandwidth situations (dialup modem), this may be relevant.

  OTOH, we may also have to ask ourselves how much effort should go into trying 
to cover old requirements.  If easy to do so, we should do so, but at the same 
time, we shouldn't spend a lot of time trying to make things work in marginal 
situations at best.

>>   and so on.  As an aside, since exp now has its own statbar, there really
>> isn't much reason for there also to be a display in the stat area.
> 
> I've noted that, and think removing it might require a code change to avoid
> error messages as missing widgets do generate them, though I have not
> checked to be sure.  It's a good reminder though.  I have thought it odd
> for some time.

  At minimum, the lookup_widget routine generates an error whenever you try to 
find a widget that doesn't exist.

  If it gets removed from all the layouts, then removing the code that updates 
the labels makes sense.

  If some layouts have it, and others don't, I think this can still get managed 
by checking for null values or the like.  An alternative may be to put those 
labels in some hidden widget that is never displayed, so the widgets are still 
there, just out of sight.