Re: [crossfire] GTK V2 client default layout and map size
I think that I suggested a solution a long time ago: highlighting the changes for the protections. Basically, every time a protection changes Something like this would be very helpful. Perhaps accompanied by a warning sound (should the user have sounds), too. This has been so big a problem, that I have considered writing a small script to recast all protection spells whenever they expire, but never got around to do that. Ideally something like a spell monitor would be nice - protections on That would require a bit more coding effort, but that would certainly be Wait a second, I don't quite follow you now. Don't we already have this? At least protection spells cause a message your protection from X is running out some time before it actually runs out. Could we not use the same code (base) for an overall monitor? This warning was actually so big improvement when it was introduced that it probably was the main reason I did not write the above mentioned script. That's right, but this also has a cost: a top-level window has some decorations that can take valuable space on smaller screens. So if you have a small display, then it is better to have as much as possible inside a single main window. You can always request a decorless window from the window manager. I think any decent ;) window manager disregards the application's request, though, since it should be the user, who decides that. But the user with such a window manager can always tell the WM to remove the decors if they are too big. rantUnfortunately, according to the above requirement, I know just two decent window managers and I know no one who uses either. Luckily most wm's are almost decent and can add/remove decors when user wants. /rant I couldn't agree more. All options that are currently hidden behind some strange combinations of button clicks and modifiers would be much more discoverable by the users if there was some kind of context menu for Agreed. Although, I hate menus - shortcut keys and mouse-key-click -combos are so much faster, when you know the magic combo. But, like you already noted, these have the problem of being obscure and hard to remember (unless you use them frequently), so having a slow way of accessing these functions is very helpful. -Juha -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] GTK V2 client default layout and map size
Juha Jäykkä wrote: I think that I suggested a solution a long time ago: highlighting the changes for the protections. Basically, every time a protection changes Something like this would be very helpful. Perhaps accompanied by a warning sound (should the user have sounds), too. This has been so big a problem, that I have considered writing a small script to recast all protection spells whenever they expire, but never got around to do that. I think highlighting protections as they change is a reasonable first step. but IIRC, there is also space issues related to fitting all the protections in the requisite area. Ideally something like a spell monitor would be nice - protections on That would require a bit more coding effort, but that would certainly be Wait a second, I don't quite follow you now. Don't we already have this? At least protection spells cause a message your protection from X is running out some time before it actually runs out. Could we not use the same code (base) for an overall monitor? This warning was actually so big improvement when it was introduced that it probably was the main reason I did not write the above mentioned script. Messages being printed tend to get lost in the shuffle, at least in a nasty battle. This is sort of why i say less is more - having less information but making the information I care about more visible may be quite useful. That's right, but this also has a cost: a top-level window has some decorations that can take valuable space on smaller screens. So if you have a small display, then it is better to have as much as possible inside a single main window. You can always request a decorless window from the window manager. I think any decent ;) window manager disregards the application's request, though, since it should be the user, who decides that. But the user with such a window manager can always tell the WM to remove the decors if they are too big. rantUnfortunately, according to the above requirement, I know just two decent window managers and I know no one who uses either. Luckily most wm's are almost decent and can add/remove decors when user wants. /rant I don't think this top level window should be the only way way to see protections, but could be a good to provide a larger/better view of the protections. Same could be said for skills and perhaps inventory. A top level window for skills could be nice - list exp, show a nice progress bar on exp to next level, maybe even have some nice context information on how to use the skills (the message portion of the skill object). At the same time, I don't think this should be the only way to see skill information - showing it under a notebook on the client is still good. In a sense, one could sort of see this with the spell window - you don't need that window to cast spells, but it can provide some nice information in a better format than just the output of 'cast' can. I think the one that could have the greatest benefit here is an inventory handling window. Aside from a current problem right now of it sometimes being a bit too small to see full information for objects, I could see a full sized window having everything you might need: Icon, item name, weight, different check boxes to denote equipped/locked/different favorite lists (one could see having a few different favorite lists - up to players how they use them - it could be based on type of foe - fire creature items list and cold creature items list, or different items, whatever. It would be even cooler to list the value of items (based on current shop and 'real' value), so one can quickly see different objects, etc. And for that matter, include the message field of the object in that list if reasonable. Depending on space, maybe include a few other key things, like damage or AC/armor values I probably wouldn't go around adventuring with such an object inventory window up, but back in town at the shop, figuring out what to sell, such a window could be quite handy way to provide more concise information (being able to sell objects through the window should still be allowed). And likewise, having all that information at hand could be really handy to see relative value of different objects (damage, ac, whatever). Right now, I often spend a lot of time examining the different objects to see what they do. I couldn't agree more. All options that are currently hidden behind some strange combinations of button clicks and modifiers would be much more discoverable by the users if there was some kind of context menu for Agreed. Although, I hate menus - shortcut keys and mouse-key-click -combos are so much faster, when you know the magic combo. But, like you already noted, these have the problem of being obscure and hard to remember (unless you use them frequently), so having a slow way of accessing these functions is very
Re: [crossfire] GTK V2 client default layout and map size
Hi! I've been following the discussion on client layouts with great concern. What makes me concerned is the fact that most people seem to be fixed on the idea that a) the game window dimensions equal screen resolution and b) the window layout is (at least almost) fixed. For point a) please note that some people (at least me) never use full screen size windows for any purpose (except on my htpc, but that does not even have a keyboard and mouse so I won't be playing on it) and the current unability to let the window manager resize the window is simply absurd. If a user wants to resize crossfire window to 20x20 pixels, it's the user's problem when if becomes totally useless. Almost all programs scale their internal window widget sizes according to the window size (or introduce scroll bars). Why would crossfire not do this? For the map-view-widget this would probably be pointless, but at least everything else could scale. Even the map widget could scale at least is tile-size steps: if 16x16 tiles no longer fit on whatever size the user adjusted the window to, then only draw 15x15 - and leave some blank if the actual size is 15.5x15.5 or resize the info widgets to fill that space. For point b) Raphaël already noted GIMP, my example would have been from gaming: FreeCiv. It has *exactly* the same situation as crossfire: a current map view based on tiles and some informative widgets displaying, for example, an overview of the whole world map etc. If you resize the window, the map view shrinks etc. No fixed map window sizes or anything. User can do whatever one likes, even float some of the widgets to separate windows (I would not like that feature myself in a real-time game like CF, but rearranging the widgets within the master window would be useful). Is there a reason for points a) and b) being as they are 1) now, 2) in the future? I hope there is no reason to keep them such in the future... -Juha -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] GTK V2 client default layout and map size
On 15/02/2008, Juha Jäykkä [EMAIL PROTECTED] wrote: For point a) please note that some people (at least me) never use full screen size windows for any purpose (except on my htpc, but that does not even have a keyboard and mouse so I won't be playing on it) and the current unability to let the window manager resize the window is simply absurd. If a user wants to resize crossfire window to 20x20 pixels, it's the user's problem when if becomes totally useless. Almost all programs scale their internal window widget sizes according to the window size (or introduce scroll bars). Why would crossfire not do this? For the map-view-widget this would probably be pointless, but at least everything else could scale. Even the map widget could scale at least is tile-size steps: if 16x16 tiles no longer fit on whatever size the user adjusted the window to, then only draw 15x15 - and leave some blank if the actual size is 15.5x15.5 or resize the info widgets to fill that space. Likewise, I prefer to place each widget in its own window, get rid of window borders for them, and just rearrange them as I see fit. This allows for easy arrangement to play on multiple monitors, as well as allowing a very flexible way of arranging the client's components to suit playing style. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] GTK V2 client default layout and map size
On Tue, 12 Feb 2008 21:44:02 -0800, Mark Wedel [EMAIL PROTECTED] wrote: 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. It depends. Since I play from time to time using different computers, I end up using different screen resolutions: 1024x768, 1280x1024, 1600x1200, etc. I think that the original gtk v2 layout isn't too bad and I can even use it at 1024x768 using a few tricks to save space. If you look carefully, you will see that the gtk v2 and the Oroboros layout are almost the same, except that the map area is moved from the top left to the bottom right. Otherwise, both are based on a basic 2-columns layout, with one column containing the same 3 rows (messages, inventory, floor view) and the other other one containing the map and the stats/skills/etc. One difference is that Oroboros puts the HP/SP/Gr/Food/Exp bars inside one of the tabs instead of besides the tabs. I do not like this choice because it means that I cannot view these very important bars as easily when I am viewing the other tabs, so that's why I still prefer the v2 layout. I think that before we try to pick the best layout, there are two things that should be investigated: 1) What information is important to the players? What should always be visible on the screen and what can be toggled in/out of view using tabs or using any other appropriate mechanism? I would like to have a discussion on what we need to show before having a discussion about how it should be shown. 2) Is it possible to make the layout more flexible? Instead of having to select among a predefined set of layouts, could we find a way to provide a good default layout while still allowing the user to change it easily? After discussing these two points, then we can go back to the selection of the best layout if this is still relevant. I will start with a few comments on point 2) because this is related to what Mark wrote: Now it may be that the client should try and be smart and choose a best default layout based on various factors, like screen resolution. Same could be said for things like map size. A better approach may be to have a basic configuration program (or window) that is used first time client is run by user (no .crossfire file). A fair number of commercial games use that approach - configure the display resolution/quality you want to use, configure sound, etc. This is not an ideal approach because it forces to to select (automatically or via some configuration program) among a set of predefined layouts and maybe none of them is perfect for you. Instead, I would prefer to start with a good layout that can work well at low resolutions (a 2-columns layout) and then allow the user to add or remove a third column at any time and pick the tabs that should be in that column. I have some experience with that in GIMP: instead of having a fixed layout for all tools and dialogs, you can create any number of docks and drag tabs into these docks or out of them. GIMP uses separate top-level windows for the docks, but this could also be done using columns belonging to the same top-level window. Once you have done the initial effort to replace/subclass the GtkNotebook widgets, you get a lot more flexibility and then you do not have to worry anymore about what layout is best, because you know that the users will be able to re-organize the tabs according to their preferences. The main concern would be to select the best initial layout, but we would not need to worry about how a 2-columns layout wastes space on a widescreen display because we will know that it is easy to add a third column if the user wants it. I'm also not wild about the way the stats are displayed in all the layouts (which really isn't changed) - that is to say being in a single row: Str 5 Dex 6 Con 10, etc as that never seems really easy to find for me, and I can't think of any other game that displays them - doing them as a column, with column to the right (or maybe several) may be more readable and more effective use of space, eg: Str 6 Speed 0.50 Dex 10Weapon Speed0.80 Con 18Damage 15 Int 14WC 6 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. A column layout might be nice for the stats. But regarding the point 1) that I mentioned above, I would be interested in a discussion about what we consider to be the most important information. Besides the map, messages and inventory, I would consider the following information to be important especially during combat and I would like a layout that allows me to see all of these things at the same time: Most important (sorted
Re: [crossfire] GTK V2 client default layout and map size
Raphaël Quinet wrote: ther tabs, so that's why I still prefer the v2 layout. I think that before we try to pick the best layout, there are two things that should be investigated: 1) What information is important to the players? What should always be visible on the screen and what can be toggled in/out of view using tabs or using any other appropriate mechanism? I would like to have a discussion on what we need to show before having a discussion about how it should be shown. 2) Is it possible to make the layout more flexible? Instead of having to select among a predefined set of layouts, could we find a way to provide a good default layout while still allowing the user to change it easily? Agree on both points. There may also be other things that make the client easier to use. Some of how the client works dates all the way back to it just be X11, where some more complicated things would have been very hard to do, but are quite easy to do with the widgets provided by GTK. A better approach may be to have a basic configuration program (or window) that is used first time client is run by user (no .crossfire file). A fair number of commercial games use that approach - configure the display resolution/quality you want to use, configure sound, etc. This is not an ideal approach because it forces to to select (automatically or via some configuration program) among a set of predefined layouts and maybe none of them is perfect for you. Instead, I would prefer to start with a good layout that can work well at low resolutions (a 2-columns layout) and then allow the user to add or remove a third column at any time and pick the tabs that should be in that column. Yes, that is a better solution. I guess it depends on how much work it is to do. One nice thing right now is that all the layout work is done in glade. This makes it very easy to try different things, but also makes it very easy to add onto the layout. So while things could be done better, I'd want to make sure we don't drift away from also being able to manage the layouts within glade. Having thousands of lines of handwritten code to handle ideal layouts may be nice from an end user perspective, but starts to get really unmanagable from a developer perspective. At the same time, the first time a person runs the client, popping up some config options may still not be a bad thing, as right now, for lots of the config options, the client chooses defaults which may not be ideal. A column layout might be nice for the stats. But regarding the point 1) that I mentioned above, I would be interested in a discussion about what we consider to be the most important information. Besides the map, messages and inventory, I would consider the following information to be important especially during combat and I would like a layout that allows me to see all of these things at the same time: I'd make some adjustments even on those key points - inventory can/should be done better. Its been discussed, but what is really needed is ability to make up a custom list of objects I care about. In combat, there are probably less than 20 items I really need to see in my inventory - things like certain scrolls and potions, and maybe a few different weapons. I don't need to see all my items, and in fact, seeing all my items often makes it difficult to get to the ones I really need. Most important (sorted by order of importance): - HP/SP/Gr/Food bars - range (current spell or bow) - important if I have the wrong thing active and I am wondering why the monsters around me are not harmed - protections (percentages for all current protections, armor) - important especially when they change because I have been hit or a spell expires. Pretty much agree. But I also think a better way to manage the protections is needed. While I want to be able to see them, being able to easily notice that my resist fire has gone from 90 to 20 may be difficult. Ideally something like a spell monitor would be nice - protections on my character are almost certainly controlled by various potions the character drinks. Because the duration of these potions can not really change, it is a fairly simple matter for the server to inform the client that 'Joe drank a potion of fire resistance, it will last for 30 seconds'. Clearly it would be done in a more concise term than that, but you get the point. So maybe some space in the statbar area could be used for this. A simple solution would be to use different icons for the different resistances/spell effects, and the client draw a little stat along with the icon, so one can see how much time is left on the spell. - AC - damage - speed - weapon speed - WC While the above are handy, they also typically are not things that change in combat, so I don't really need to see them in a glance. At some point, less
Re: [crossfire] GTK V2 client default layout and map size
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? Now it may be that the client should try and be smart and choose a best default layout based on various factors, like screen resolution. Same could be said for things like map size. A better approach may be to have a basic configuration program (or window) that is used first time client is run by user (no .crossfire file). A fair number of commercial games use that approach - configure the display resolution/quality you want to use, configure sound, etc. That, however, is a fair amount of work, and ideally, the configuration dialogs used within the client match those initial configuration ones (don't duplicate code, but also easier for an end user perspective - if you see one set of configuration dialog the first time you run it that doesn't match the one you see later, may be harder to know what config options you used before, etc) If a user supplies a layout, it could get really hard to have all the necessary information where it would all work just right. It does make sense to pick Oroboros automatically on desktops at 1024x768 or lower. 1280x1024 and higher have always been supported on this client, so auto-picking once in that range seems not to buy much advantage, and none of them default to sizes that won't fit at all on that resolution. On IRC, people seem to be saying that 800x600 is still alive and kicking too. I figured I'd hammer a bit on Oroboros to get one option at that size, so having one of those to pull out of the hat if someone launches it on a small desktop might be good. As for a configuration program, what I can see is showing thumbnails of clients and let people browse them, along with the text descriptions, possibly calling out the default size of the layout separately. Doing something like that, you could advise against certain layouts based on the desktop size, but could allow them to be selected anyway if they want to try to deal with the resizing. That said, I think it needs to stay simple, but even so, presently there are better ways to spend a lot of development time. People still complain too much about what isn't there, and a configuration program won't address what gets complained about the most. 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. Note that one reason I put the map window in the upper left corner is that to some extent it made using different map sizes easier. But I do have to say I don't find it ideal either (but I'm not sure what I find ideal). There are two options in the screen shots. Some that put the map on one side, and others. I'm also not wild about the way the stats are displayed in all the layouts (which really isn't changed) - that is to say being in a single row: Str 5 Dex 6 Con 10, etc as that never seems really easy to find for me, and I can't think of any other game that displays them - doing them as a column, with column to the right (or maybe several) may be more readable and more effective use of space, eg: Str 6 Speed 0.50 Dex 10Weapon Speed0.80 Con 18Damage 15 Int 14WC 6 Hmm. Three layouts already do something like this. The first layout on Leaf's listing is very different, and not unlike what you describe. http://krayvin.home.att.net/caelestis_790x600.png Further, all the layout screenshots do not expose the stats, so unless one opened them, it would be difficult to say they hadn't changed. Chthonic, Oroboros do use columns as well. The GTK V1 variants do not for more obvious reasons, but for the others, I'll be most happy to do something different as it would free up more screen area. Remember too, I copied the legacy GTK V2, and differentiation occurs somewhat over time as I play with ideas. Keep suggestions coming. Oddly, when I mentioned stats and the homogenous mode before, the gtk-v2 format was argued for, possibly giving some exception to allowing numbers to cuddle the label. I imagine that
Re: [crossfire] GTK V2 client default layout and map size
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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] GTK V2 client default layout and map size
It is probably time to seriously consider changing the default layout of the GTK V2 client. It seems a not infrequent complaint that the current layout is not helping people appreciate GTK V2, and this was the primary reason I did work on GTK V2 since it was the entire reason GTK V2 was unacceptable for my use. Leaf has been kind enough to put up sample layouts at: http://crossfire.real-time.com/clients/gtkv2_client.html Even if the default is not changed immediately, a poll could be put up somewhere to start collecting data. That would at least help put some numbers to the situation instead of general impressions based on IRC comments. My opinion: I think meflin.glade and gtk-v2.glade are not viable candidates due to a number of reasons (map size/default window size), though I'd not avoid letting people vote on them. meflin.glade is definitely more of an expert player's layout, due to the messages/inventory being on different tabs such that you can't see the text displayed if you click on a floor or inventory icon. GTK V1 is not really that great, either IMO. Both Un-Deux and V1-Redux are better if going for a V1-ish look. If a layout is selected that is most likely to be compatible with all desktop sizes, oroboros.glade is the winner there because it has saved defaults that easily fit on a 1024x768 display, though personally, it has too many tab notebooks. In the end, it seems best to let players choose by vote, if only because the layout is tied so much to personal taste. I do think that the default map size in the configuration should be changed. 25x25 is not a practical size for many people, besides having a performance cost. It would be good to consider also selecting new default map sizes - possibly based on either the lowest common denominator of 17x13 (Oroboros driving the 13), or 17x17 by culling a couple of the two smallest layouts (Oroboros/GTK V1) and going with 17x17. Feedback anyone? Kevin Bulgrien ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
