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


Previous by date: 28 Nov 2000 12:51:09 -0000 subscribe mail!, bob zhu
Next by date: 28 Nov 2000 12:51:09 -0000 Re: Makefile.rules, Jordan Crouse
Previous in thread: 28 Nov 2000 12:51:09 -0000 Re: Improved keyboard event handler and mouse motion event handler for flnx, Greg Haerr
Next in thread: 28 Nov 2000 12:51:09 -0000 Re: Improved keyboard event handler and mouse motion event handler for flnx, Greg Haerr

Subject: Re: Improved keyboard event handler and mouse motion event handler for flnx
From: Morten Rolland ####@####.####
Date: 28 Nov 2000 12:51:09 -0000
Message-Id: <3A23AB04.1B1F4A88@screenmedia.no>

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.

Previous by date: 28 Nov 2000 12:51:09 -0000 subscribe mail!, bob zhu
Next by date: 28 Nov 2000 12:51:09 -0000 Re: Makefile.rules, Jordan Crouse
Previous in thread: 28 Nov 2000 12:51:09 -0000 Re: Improved keyboard event handler and mouse motion event handler for flnx, Greg Haerr
Next in thread: 28 Nov 2000 12:51:09 -0000 Re: Improved keyboard event handler and mouse motion event handler for flnx, Greg Haerr


Powered by ezmlm-browse 0.20.