Re: [crossfire] gcfclient and sign display
Le Mercredi 17 Août 2005 06:07, Mark Wedel a écrit : > tchize wrote: > > Le Mardi 16 Août 2005 09:30, Mark Wedel a écrit : > > > >> I should probably preface that I'm responsible for the 'nopopup' mode in > >> the > >>gtk client (v1). > > > > > > What is? > > run with -nopopups command line option. > > Without it, gtk client pops up window for player name, password, and some > other things. > > With that option, player name and like is entered in the text dialogue box. Didn't know this mode existed. Then it also conflict with new login window (the one including news, motd, rules). Need to be fixed :) > > > > > > >> But does anyone else find the sign display code in the client really > >> annoying? > >> To me, these are the major issues: > >> > >>1) No way to turn it off, save for code modification. > > > > > > First comments on it i receive since implemented. Disabling for those > > requesting it should be easy to code. > > > > Please do so, ideally adding a config option that shows up in the config > menus > and is saved in the config file (eg, like all the other config options). Will check at this. > > This is a relative new feature, so not positive how many people are really > using it, which could be one reason relative to comments. Well, this is present in cvs since a bit of time, but no public server had switched ot latest cvs code. > > > > >>2) It centers it on the screen, not the client. This is bad behaviour, > >>especially for those of us with dual monitor setups (I really don't need it > >>straddling the monitors) > > > > > > GTK centering behaviour, do not know much of gtk to know how to correct > > this. > > I recall there is an option to center it on the application and not the > screen. I don't know it off the top of my head, but I think the magicmap > code > (which creates a popup) uses that. I'll take alook, no promises i will find out. > > > > > > >>3) It shifts input focus to the sign area itself, thus the client stops > >>receiving useful input (like movement commands) > > > > > > Quite obviously, you are *reading* the sign, not doing much more else. This > > seems to me > > a normal roleplay behaviour. If you have any better idea... > > There shouldn't be any reason it needs to shift input focus. I can move > the > mouse to get focus on the main screen again with the sign still up. > > Alternatively, any input it receives should just get passed along to the > client where applicable (mouse presses aren't, keystrokes are) > > My concern here is as more objects get this support, it can mess up > players. > Imagine what happens if the wrong scroll gets applied while in the middle of > combat (a scroll containing info vs that scroll of restoration) - not only > did > you get the wrong scroll, but until you move the mouse around, the client > stops > getting any input, likely resulting in a dead character. could you re-explain the whole thing? I simply don't grab your point. You mean while the sign is visible and you are reading it, player should be able to to still apply his inventory scroll or cast spell ?? For know, expected behaviour is sign is showed. Read it, dismiss it, and everything is back to normal! Unless some bug there :/ > > > > > > >>4) No button or the like to dismiss it - have to use whatever functionality > >>your > >>window manager provides to dismiss it. > > > > > > Could be added i suppose, though i don't see why the window manager way of > > closing > > windows is an issue. > > Requires moving the mouse and clicking. Normally, once I start playing, I > tend not to need to move the mouse for large stretches, and when I do use so, > it > is then continuously for a little while (selling those items). alt-f4? (or any other magic key from window manager?) > > But this also goes up a bit to the one above - the comment about a key > press > (or specifically, 'a',) dismissing it seems quite reasonable. To me too, except it conflicts with your previous idea of sending key event to main windows to apply scrolls (apply is 'a' on my client) > > The first time this happened to me, it took several seconds to figure out > it > was this pop up sign. IMO, this is not a good/intuitive design then. Well, probably the popup should not be hideable, i suppose you saw the sign and switched to main window without closing it. Probably a gtk issue, i used it as a popup, a popup is supposed to stay upward and not be hidden by main window. Seems i need a bit more gtk related inquiries to guess where it comes from. > > > >> But when I first saw this proposal, I had envisioned that it'd do > >> something > >>clever with the text window (draw graphics, whatever), not put in pop up > >>windows. > > > > > > > > GTK too limited to do 'something clever' like draw graphics in the text > > window. > > Moreover, if my memory don't fail, concerning signs, i never suggest
Re: [crossfire] gcfclient and sign display
Brendan Lally wrote: On 8/16/05, tchize <[EMAIL PROTECTED]> wrote: Even better would be if the food value were a role against Int, and if recalling a sign with a low food value corrupted the message (arbitrarily transposed some words, or mispelt some things) - the recall then, would be the memory of the /character/, and not the player. The problem with that is then the players will just copy/paste the contents of important signs into text editors or whatever. Unless there was a hook to actually require the character have read and remember the sign, all it really does is add more bother to the player. And that's something I'd want to avoid at some level. My real beef about the signs wasn't long term memory. There are several maps that have a sign early on in the map which contain info related to finishing the map(s). Being able to find that information without having to visit the sign again is nice, and the current implementation doesn't have that. With the multiple text windows, sign messages don't get lost that often (but this depends on frequency of people chatting). So all I really wanted was some way to have that info there - putting a copy in the text window works fine or me. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient and sign display
tchize wrote: Le Mardi 16 Août 2005 09:30, Mark Wedel a écrit : I should probably preface that I'm responsible for the 'nopopup' mode in the gtk client (v1). What is? run with -nopopups command line option. Without it, gtk client pops up window for player name, password, and some other things. With that option, player name and like is entered in the text dialogue box. But does anyone else find the sign display code in the client really annoying? To me, these are the major issues: 1) No way to turn it off, save for code modification. First comments on it i receive since implemented. Disabling for those requesting it should be easy to code. Please do so, ideally adding a config option that shows up in the config menus and is saved in the config file (eg, like all the other config options). This is a relative new feature, so not positive how many people are really using it, which could be one reason relative to comments. 2) It centers it on the screen, not the client. This is bad behaviour, especially for those of us with dual monitor setups (I really don't need it straddling the monitors) GTK centering behaviour, do not know much of gtk to know how to correct this. I recall there is an option to center it on the application and not the screen. I don't know it off the top of my head, but I think the magicmap code (which creates a popup) uses that. 3) It shifts input focus to the sign area itself, thus the client stops receiving useful input (like movement commands) Quite obviously, you are *reading* the sign, not doing much more else. This seems to me a normal roleplay behaviour. If you have any better idea... There shouldn't be any reason it needs to shift input focus. I can move the mouse to get focus on the main screen again with the sign still up. Alternatively, any input it receives should just get passed along to the client where applicable (mouse presses aren't, keystrokes are) My concern here is as more objects get this support, it can mess up players. Imagine what happens if the wrong scroll gets applied while in the middle of combat (a scroll containing info vs that scroll of restoration) - not only did you get the wrong scroll, but until you move the mouse around, the client stops getting any input, likely resulting in a dead character. 4) No button or the like to dismiss it - have to use whatever functionality your window manager provides to dismiss it. Could be added i suppose, though i don't see why the window manager way of closing windows is an issue. Requires moving the mouse and clicking. Normally, once I start playing, I tend not to need to move the mouse for large stretches, and when I do use so, it is then continuously for a little while (selling those items). But this also goes up a bit to the one above - the comment about a key press (or specifically, 'a',) dismissing it seems quite reasonable. The first time this happened to me, it took several seconds to figure out it was this pop up sign. IMO, this is not a good/intuitive design then. But when I first saw this proposal, I had envisioned that it'd do something clever with the text window (draw graphics, whatever), not put in pop up windows. GTK too limited to do 'something clever' like draw graphics in the text window. Moreover, if my memory don't fail, concerning signs, i never suggested doing anything else than show sign content inside a sign graphic. And unless i miss something, having a popup show up when you apply a sign and not be able to fight is not really a problem, unless you start applying signs while fighting?? See comment above, or do you not plan to extend it to things likes books and scrolls (I seem to recall that was on the list of things to do). I can understand that there is limitation with the text window. But I thought it was possible to draw graphics in the text window (was marginally more complicated, but still possible) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient and sign display
Le Mardi 16 Août 2005 13:07, Brendan Lally a écrit : > On 8/16/05, tchize <[EMAIL PROTECTED]> wrote: > > Le Mardi 16 Août 2005 09:30, Mark Wedel a écrit : > > > > > > > 4) No button or the like to dismiss it - have to use whatever > > > functionality your > > > window manager provides to dismiss it. > > > > Could be added i suppose, though i don't see why the window manager way of > > closing > > windows is an issue. > > > actually, I would have to support this point, there needs to be a > close button that is focused by default, ideally also bound to the > shortcut key 'a' so that pressing 'a' over a sign would act like a > toggle. > ok > > > > > > 5) Since info appears in that window, it does not appear in the normal > > > windows, > > > thus, once destroyed (or you read another sign), you lose the contents. > > > Thus, > > > that information on the sign at the start of the dungeon may effectively > > > be lost > > > (won't be in scrollback buffer). > > > > I guess it could be duplicated in normal text windows. > > Storage of information strikes me as something more suitable for Ryo's > quest management system (once he decides how to reimplement it) rather > than buried somewhere in the middle of lots of kill information in the > still-crowded text windows > > One thing that might also be interesting though would be if applying a > sign would give an invisible object with a copy of the text and a food > value. This would then gradually disappear, and there could be a > recall command to popup a sign window containing a copy of the > message. > > Even better would be if the food value were a role against Int, and if > recalling a sign with a low food value corrupted the message > (arbitrarily transposed some words, or mispelt some things) - the > recall then, would be the memory of the /character/, and not the > player. > > Obviously rereading the original sign would need to reset the food value. > Out of topic considering we are speaking of client side handling of signs. This all has to do with server side quest system enhancements. Regards. > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient and sign display
On 8/16/05, tchize <[EMAIL PROTECTED]> wrote: > Le Mardi 16 Août 2005 09:30, Mark Wedel a écrit : > > > > 4) No button or the like to dismiss it - have to use whatever functionality > > your > > window manager provides to dismiss it. > > Could be added i suppose, though i don't see why the window manager way of > closing > windows is an issue. > actually, I would have to support this point, there needs to be a close button that is focused by default, ideally also bound to the shortcut key 'a' so that pressing 'a' over a sign would act like a toggle. > > > > 5) Since info appears in that window, it does not appear in the normal > > windows, > > thus, once destroyed (or you read another sign), you lose the contents. > > Thus, > > that information on the sign at the start of the dungeon may effectively be > > lost > > (won't be in scrollback buffer). > > I guess it could be duplicated in normal text windows. Storage of information strikes me as something more suitable for Ryo's quest management system (once he decides how to reimplement it) rather than buried somewhere in the middle of lots of kill information in the still-crowded text windows One thing that might also be interesting though would be if applying a sign would give an invisible object with a copy of the text and a food value. This would then gradually disappear, and there could be a recall command to popup a sign window containing a copy of the message. Even better would be if the food value were a role against Int, and if recalling a sign with a low food value corrupted the message (arbitrarily transposed some words, or mispelt some things) - the recall then, would be the memory of the /character/, and not the player. Obviously rereading the original sign would need to reset the food value. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient and sign display
Le Mardi 16 Août 2005 09:30, Mark Wedel a écrit : > > I should probably preface that I'm responsible for the 'nopopup' mode in > the > gtk client (v1). What is? > > But does anyone else find the sign display code in the client really > annoying? > To me, these are the major issues: > > 1) No way to turn it off, save for code modification. First comments on it i receive since implemented. Disabling for those requesting it should be easy to code. > > 2) It centers it on the screen, not the client. This is bad behaviour, > especially for those of us with dual monitor setups (I really don't need it > straddling the monitors) GTK centering behaviour, do not know much of gtk to know how to correct this. > > 3) It shifts input focus to the sign area itself, thus the client stops > receiving useful input (like movement commands) Quite obviously, you are *reading* the sign, not doing much more else. This seems to me a normal roleplay behaviour. If you have any better idea... > > 4) No button or the like to dismiss it - have to use whatever functionality > your > window manager provides to dismiss it. Could be added i suppose, though i don't see why the window manager way of closing windows is an issue. > > 5) Since info appears in that window, it does not appear in the normal > windows, > thus, once destroyed (or you read another sign), you lose the contents. > Thus, > that information on the sign at the start of the dungeon may effectively be > lost > (won't be in scrollback buffer). I guess it could be duplicated in normal text windows. > > 6) At least as things are now, it doesn't really add much. > An awfull picture (unless gfxers finally did draw a nice background for signs) > I guess the key issue is #1 - then people can just turn it off, and anyone > who > uses it is basically choosing to live with points 2 through 5 (or they aren't > important). > > But when I first saw this proposal, I had envisioned that it'd do something > clever with the text window (draw graphics, whatever), not put in pop up > windows. GTK too limited to do 'something clever' like draw graphics in the text window. Moreover, if my memory don't fail, concerning signs, i never suggested doing anything else than show sign content inside a sign graphic. And unless i miss something, having a popup show up when you apply a sign and not be able to fight is not really a problem, unless you start applying signs while fighting?? Regards > > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] gcfclient and sign display
I should probably preface that I'm responsible for the 'nopopup' mode in the gtk client (v1). But does anyone else find the sign display code in the client really annoying? To me, these are the major issues: 1) No way to turn it off, save for code modification. 2) It centers it on the screen, not the client. This is bad behaviour, especially for those of us with dual monitor setups (I really don't need it straddling the monitors) 3) It shifts input focus to the sign area itself, thus the client stops receiving useful input (like movement commands) 4) No button or the like to dismiss it - have to use whatever functionality your window manager provides to dismiss it. 5) Since info appears in that window, it does not appear in the normal windows, thus, once destroyed (or you read another sign), you lose the contents. Thus, that information on the sign at the start of the dungeon may effectively be lost (won't be in scrollback buffer). 6) At least as things are now, it doesn't really add much. I guess the key issue is #1 - then people can just turn it off, and anyone who uses it is basically choosing to live with points 2 through 5 (or they aren't important). But when I first saw this proposal, I had envisioned that it'd do something clever with the text window (draw graphics, whatever), not put in pop up windows. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
