nanogui: Thread: Improved keyboard event handler and mouse motion event handler for flnx

Hi Greg and others,
    We are now working with microwindows-0.89pre5 and flnx-0.14.
    Thank you for your great work that many problems were solved in these two newest released version.
    But keyboard events processor is still incomplete and needs more work to be done. When press some special key(such as F10), a sequence of key press events is generated by nano-X. If we use a Fl_Input widget, it will result in a string as "[21~".
    I did some work to solve this problem. All work is done in the flnx source file <Fl_x.cxx>. New added or modified code is marked with "MaTeng".
    It is a simple but unperfect way. I just handle the keyboard press event. When meet special key, I record its string and match it in a key-map array, then forward. Now it seems work well.
    I met another problem. When use framebuffer, the demo program scroll.cxx seems to be very inefficent while draging the scrollbar. The refresh rate is too slow. I made some modification to the method fl_wait() to filter the mouse motion event. Now, it looks better but still can not meet our needs. How can I solve this problem? 
    The last problem is after pressing CTRL_C in flnx demo program editor, I can not get keypress event any more from the nano-X server. I had to stop nano-X and restart it.
    Since I am not familiar with nano-X, I think my modification is incomplete and maybe there is some other better way. Your advice will be very important and useful to me.
    By the way, I am glad to commit my modification and wish it will do you good.
    The attachment is a winzip archive file.

Best regards!

####@####.####
P.R.China

Over the weekend I have completed a major keyboard design for
Microwindows, and have written scancode drivers for framebuffer
and X11.  With this new design, there is no need or desire for the
escape-sequence processing that was previously required.

Instead, the new design always returns a 16-bit unicode value
for all keystrokes, press and release.  The function, arrow and
special keys are placed in the UC16 private use area so there's
no overlap with other glyphs.  In addition, the lower 256 codes
are mapped to latin-1.  This has necessitated some API
changes with the GR_EVENT_KEYSTROKE as well as
GrInjectKeyboardEvent.

We are working on FLNX changes to be completly compatible
with this version, which will be released as 0.89pre7.

In order to fully test the keyboard, I have ported Doom! to
Microwindows, and it runs great.

These changes should correct all your keyboard issues with
Microwindows.  The Century folks have fixed FLNX with better
scrollbar handling, including double-buffered output for ViewML,
for instance.

Regards,

Greg
  ----- Original Message ----- 
  From: mateng 
  To: ####@####.#### 
  Cc: ####@####.#### 
  Sent: Sunday, November 26, 2000 6:39 PM
  Subject: Improved keyboard event handler and mouse motion event handler for flnx


  Hi Greg and others,
      We are now working with microwindows-0.89pre5 and flnx-0.14.
      Thank you for your great work that many problems were solved in these two newest released version.
      But keyboard events processor is still incomplete and needs more work to be done. When press some special key(such as F10), a sequence of key press events is generated by nano-X. If we use a Fl_Input widget, it will result in a string as "[21~".
      I did some work to solve this problem. All work is done in the flnx source file <Fl_x.cxx>. New added or modified code is marked with "MaTeng".
      It is a simple but unperfect way. I just handle the keyboard press event. When meet special key, I record its string and match it in a key-map array, then forward. Now it seems work well.
      I met another problem. When use framebuffer, the demo program scroll.cxx seems to be very inefficent while draging the scrollbar. The refresh rate is too slow. I made some modification to the method fl_wait() to filter the mouse motion event. Now, it looks better but still can not meet our needs. How can I solve this problem? 
      The last problem is after pressing CTRL_C in flnx demo program editor, I can not get keypress event any more from the nano-X server. I had to stop nano-X and restart it.
      Since I am not familiar with nano-X, I think my modification is incomplete and maybe there is some other better way. Your advice will be very important and useful to me.
      By the way, I am glad to commit my modification and wish it will do you good.
      The attachment is a winzip archive file.

  Best regards!

  ####@####.####
  P.R.China



------------------------------------------------------------------------------


  ---------------------------------------------------------------------
  To unsubscribe, e-mail: ####@####.####
  For additional commands, e-mail: ####@####.####

Greg Haerr wrote:
> 
> Over the weekend I have completed a major keyboard design for
> Microwindows, and have written scancode drivers for framebuffer
> and X11.  With this new design, there is no need or desire for the
> escape-sequence processing that was previously required.

This is great news, this is a much more elegant and flexible way
to handle keypresses.

> Instead, the new design always returns a 16-bit unicode value
> for all keystrokes, press and release.

I would suggest using 32-bit UNICODE code points instead of 16-bit
unicode.  16-bit Unicode is starting to run into trouble with too
few glyphs, and I don't see how you can cleanly handle aggregates
with only 16-bit unicode values in each event.  True, this project
try to be small and fast, but adding 16 bits of mostly zeroes to
keyboard events will not hurt performance, but increase the
lifespan of the API.

What happens when you want to "compose" a character, like pressing

    ~ A

To get Ã?  One can argue that this should be handled by the
windowing system, and not each single application.
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
on the second key press (when pressing the 'A')?

This is just a thought, I think the GGI project has more ideas in
this area about how to differentiate the differeses between 
"physical" and "logical" characters/keys.

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.

> In order to fully test the keyboard, I have ported Doom! to
> Microwindows, and it runs great.

:-)

Best regards,
Morten Rolland, Screen Media.

: 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

Greg Haerr wrote:
> 
> 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.

This is not so good for games though, in case you want, say, the
<'> key to trigger something, while at the same time it is
configured to be a compose key.  It would be easier for the game
if it didn't have to know about compose keys at all (there may be
several different ones, like ^ ~ ` ' " active at the same time,
although I'm no expert on this at all since we don't use compose
keys for Norwegian, anyone else knows more about this?).  I'm
not even sure "compose key" is the proper name for this..

If the game could look for "physical key <'>", it wouldn't have to
have any more logic.

> 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.

Yes, but you may have several different compose keys and
the need for more logic in the "raw" case.

> 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.

I'm sorry, but I don't have any such info.  As I said, we don't
use them in our native language.  My guess would be that if you
have a look at the latin-1 character set, there are lots of
a,e,o,u,n with a set of ~ ` ^ ' " above them.  There are characters
that I can't possibly guess the compose sequence for, like
'c' with a ',' underneath -- I don't think the comma would be
a compose character for this one... (I don't remember the  proper
name for that little thing*).

For touch screen applications, like ours, all of this will be
done in the virtual keyboard software, as multiple key-presses
on a touch screen is not yet all that usefull....:-)   E.g. we
will make a keyboard suitable for text entry only...

Regards,
Morten Rolland