[crossfire] Improved/redone client.

[Mark Wedel]

  Quick note - the client reorganization/cleanup/entire discussion is aimed at 
the 2.0 branch.  I don't really forsee many of things things going into the 1.x 
client.


  Will try to quickly catch up with all the issues at once :

Keybind profiles:  I think that is doable, and makes sense (keybinding for a 
spellcaster vs non spellcaster is quite a bit different).  From what was 
described, it sounds like there would be two keybinding profiles in use at any 
time - the common set, and then the specialized one for the given character 
type.  That gets more complicated, because if you add a new binding, have to 
record where it goes (specialized binding or general one).  It certainly 
wouldn't be hard to have an option on what keybinding profile to use.  OTOH, 
presumably players would want this somewhat intelligent (if I play character X, 
use this binding, if I player character Y, use that binding), but probably don't 
want one binding selection per character.  And even keying on character names 
may not be good, as different types of characters with the same name could be 
played on different server.

Keybinding interface: I don't think anyone mentioned this, but I know people 
have said they don't like the current interface in the gtk2 client (which is 
really the same as the one in the gtk client).  Not positive how to improve it - 
it seems with the number of spells, etc, we're always going to have a lot of 
keybindings in crossfire, but would be interested in hearing ideas.

GTK2 client resolution: Yes, it is/was aimed at higher resolution screens.  One 
reason was there is lots of buggy/complicated code in the gtk1 client to try and 
adjust based on window size, etc, and I want to avoid that complication in the 
gtk2 client.  And at some level, I think that making changes to layout based on 
screen resolution has other disadvantages (it's hard to optimize for both low 
and high resolutions, which is one problem I had with the gtk1 client - fine on 
moderate resolution systems, but not very good on high res).  I'm not sure the 
perfect solution here, but perhaps designing a layout for 1024x768 and seeing 
how it works might be a good start.  The doc that says I won't take patches for 
lower resolution is not accurate.

Containers: How to handle them can always be a bit of pain.  I never thought it 
opening on the ground beneath the player was very intuitive (and would then 
create odd issues like you can't get to objects on the ground with an open 
container, etc).  A quick fix for closing containers in the inventory is a 
'close all containers' button could be added to the top of the inventory area.

Quick item handling: In the ideal world, the client should be able to support 
some better form of filtering, perhaps even having like a 'favorites' tab which 
only shows items marked as your favorite (in this way, you could put all your 
items that you frequently apply there).  Some games have the 'paper doll' type 
interface - I think that could still be a good idea for equipping, but I'm not 
sure if it is good during general purpose play (I can't think where that would 
fit in the client)

Map size:  The 19x19 was to make that the only supported map dimension as far as 
protocol/setup is concerned for viewable player map.  The game map files won't 
change.  And the client could of course have a larger visible map, but just 
wouldn't get data from the server for it, so its only use would be to use that 
for fog of war.  I tend to think that letting the player select map size doesn't 
have much in the way of downside (yes, some players may get more information, 
but that hasn't seemed to have been a big problem in the past)

Fullscreen client:  The reason I don't think changing resolutions should be a 
method is because I don't think that will be very well supported.  There is no 
guarantee what resolutions the system may support.  I can certainly see people 
with LCD only having 1 valid resolution defined (native resolution of the 
screen).  And you get the complication of widescreen (its not 1280x1024, but 
1280x800).  So you're now in a case where you may still need to support several 
resolutions.  The other problem is that the client has to be more bulletproof to 
change the resolution back to the original when done.  But the interesting point 
about fullscreen client, is that while several people say it may be useful, I 
don't think I've seen anyone actually say that is what they would use (they 
would use windowed mode).  Which to me sort of suggests that this isn't 
something really worth pursuing - we're trying to guess what other people want.

Pop up inventory window:  I'm perhaps seeing this more as a secondary interface 
to the inventory, not the only way.  So the existing scrollbar exists, but when 
dealing with lots of store, or perhaps more advanced operations, a pop up window 
could provide a better interface.  OTOH, having two different interfaces would 
seem confusing.

Icons & tooltips:  My idea here is to try and convey the same data, but in 
smaller space.  For example, for skills, we could probably use a quarter of the 
space by having an icon for the different skills, and then a small progress bar 
that shows progress towards next level.  The tooltip would come into player if 
your mouse hovers over the icon/progress bar - it would pop up the tooltip with 
the skill name, level, and precise exp values.

Themes: Initial thought is to make sure the client is fully themable, and then 
write some theme files that the player can select in the config window (with a 
default/inherit from system as an option).  This matches what a lot of other 
programs do - have the ability to change appearance on themes.  I don't think 
there is any downside on this, other than the work to add the theme support.

Inventory control via keyboard:  I'd be interested in how people think that 
should work - I really can't envision much any reasonable way to control the 
inventory only by keyboard, whether we use gtk2 widget or write our own.  I'd 
personally consider this to be a pretty low thing to do.

SDL removal:  The old built in draw mode of gtk will always remain.  I just 
don't think it makes sense to have 3 different drawing modes (gtk, opengl, sdl). 
  I'm prooposing just gtk and opengl.

Protection display changing colors:  That works, but is only useful if you have 
the protection tab displayed (but that is like most things I suppose).  Knowing 
if a change is temporary or permanent is much harder.  By the time the server 
gets to sending that resistance values to the client, it only knows what the 
current values are and what the old values are.  It has no idea what caused the 
change.  I suppose code could be added to change_abil(), I'm not sure how 
reliable that will be.  But related to this is the changing to draw_ext_info - 
the start and stop of protection related messages will have their own types, so 
the client will also be able to more prominently display such messages.

Extra space in gtk2 client:  I'm thinking the extra space in the stats display 
(sp/hp/grace/good) could perhaps be used for an experience bar.  In terms of 
smaller icons for inventory, that should already be supported by using the 
-iconscale option (I think that is also in the config options) - scale them down 
to a smaller size.  Perhaps the correct thing is the default should have them 
scaled down and not use the default.  Also, I think some of that extra area in 
the stats display is to denote caps/shift keys being depressed (you can 
sometimes get odd behaviour by having one of those keys pressed, leaving the 
window, and client doesn't catch that, which is why they are noted).  But all 
that info could fit in just one line.