[crossfire] gcfclient and sign display
tchize
tchize at myrealbox.com
Wed Aug 17 03:32:27 CDT 2005
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 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).
This is already done with books, except for books it's not a popup (does not
monopolize input focus) and it keep a book tab for history (i thought it
was more important for books than for signs). However, i guess i could use the
the same code as for books in signs.
>
>
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)
nope, i tried. Only thing you can do is put the text area on top of a picture
but it is still tricky :) gtk1 is very limited on this part. gtkhtml is able to do it
i think but the counter part is it's difficulty to have it working under windows :D
>
>
>
_______________________________________________
>
crossfire mailing list
>
crossfire at metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
>
>
More information about the crossfire
mailing list