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. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire