nanogui: Improved keyboard event handler and mouse motion event handler for flnx
Subject:
Re: Improved keyboard event handler and mouse motion event handler for flnx
From:
"Greg Haerr" ####@####.####
Date:
28 Nov 2000 17:41:13 -0000
Message-Id: <049601c05962$b1819320$15320cd0@gregh>
: This is great news, this is a much more elegant and flexible way
: to handle keypresses.
I'm glad you like it, I was a little worried that you might want
to stay with the previous design, which of course was your
submission.
: I would suggest using 32-bit UNICODE code points instead of 16-bit
At this point, it's as easy as changing the MWKEY typedef
from unsigned short to unsigned long in mwtypes.h
: How about making the first '~' produce a key press/release pair
: with the proper "physical key identification", but without any
: "character" information, because the character is only delivered
I'll take a look at compose key processing. I like your idea,
with a system-defined compose key, we would send a 0
ch value for the compose key, and then a calculated value on
the final compose keypress in the ch member. In this way,
games work as you mentioned. Actually, as I think of it,
on the first press, we would send MWKEY_COMPOSE,
followed by the calc'd value on the next down keystroke.
If you've got some up-to-date compose key value tables
with correct latin-1 or unicode-16 values, please send them
to me, and I'll add this. I'll also take a look at ggi.
: Typically, a game would look for the physical key events, while
: a text input application would benefit from the wisdom of
: microwin/nano-X by looking at the logical character fields.
Yes. However, note that in this design, there's really no difference
between logical and physical character fields, since there's only
one field. The difference is that the field will be either 0 for
an unknown character (this currently never happens) or it
will be replaced with a calculated value or MWKEY_COMPOSE.
Regards,
Greg
