Improve handling of chars and virtual keys in input driver stack

Project:JNode Core
Component:Code
Category:task
Priority:normal
Assigned:Stephen Crawley
Status:active
Description

The current JNode approach to handling keyboard input is a bit of a mess. Each keyboard layout is represented by a KeyboardInterpreter class. These classes use a combination of tables and code to map physical codes (scan codes, etc) from the keyboard to JNode KeyboardEvents that contain a character and a virtual key code + modifiers. These are consumed by the KeyboardReader which uses both the vk code and the character information depending on the circumstances. If the events need to be processed by an AWT application, they have to be converted to AWT KeyEvents. Most of this is hard to understand and poorly documented. IMO, a lot of it is poorly thought out; it just evolved ...

I think we need to make (at least) the following improvements:

  1. We should get rid of KeyboardEvent and use KeyEvent exclusively.
  2. The KeyboardInterpreter should be refactored so that keyboard layouts can be loaded from files.
  3. The mapping of scan codes to virtual key codes should be separate from the mapping of virtual key codes to (Unicode) characters. The latter mapping should be soft.
  4. The core KeyboardInterpreter code needs to be more capable. For example it needs to be able to support modal keyboards like the Russian keyboard in which AltGr toggles between Cyrillic and Latin. Similarly, it needs to cope with the weird and wonderful Japanese and Chinese keyboards. (Whether this support should be hard-wired into code or "programmable" is an interesting question.)
  5. The Keyboard Reader should use an event's virtual key codes exclusively for deciding what to do with the event. This would eliminate the need to soft binding both characters and virtual keys to actions in a KeyEventBinding ... and would simplify life for the user.
  6. The Keyboard Reader needs to support the equivalent of UNIX's 'raw' and 'cbreak' tty modes, together with a mode in which unmapped virtual keys events turn into sequences that an application to read via the keyboard input stream / reader.

There is a lot of work to do here ...

#1

Submitted by Fabien D on Sun, 10/12/2008 - 06:25.

About point 1, I understand why you want to remove KeyboardEvent but I think keyboard drivers (and lower layers of JNode) shouldn't depend on awt.

#2

Submitted by lsantha on Sun, 10/12/2008 - 07:17.

This stuff should not depend on AWT.
I think these issues will be more relevant later and there are more important things to be done at the moment.

#3

Submitted by Stephen Crawley on Sun, 10/12/2008 - 07:55.

The JNode core already depends on the AWT KeyboardEvent class. KeyEvent, KeyboardReader and all of the KeyboardInterpreter classes use the VK codes and modifier masks defined by KeyboardEvent.

#4

Submitted by lsantha on Sun, 10/12/2008 - 08:06.

Yes, but that is a quite weak dependency.

#5

Submitted by Stephen Crawley on Sun, 10/12/2008 - 09:18.

You are splitting hairs. It is a dependency. If dependencies on AWT are against the rules then the keyboard driver implementation is breaking the rules.

But frankly I think this is all nit-picking. The more important problems are 2 through 6 listed in the issue. However I'm sure I can find something else to do if you (Levente) think this stuff should not be done.

#6

Submitted by lsantha on Sun, 10/12/2008 - 09:26.

Please see the difference between compile time dependecy and runtime dependency.

I only think about the other points that at the moment there are more important things to do.
Please check your mailbox for an invitation to a discussion.