Keyboard events

Mouse events in Subcanvas now mostly work. A canvas's target now receives mouse movement events, mouse button press and release events and canvas enter and exit events. Now, I've moved my attention to keyboard events.

There are three types of keyboard events in Squeak: Key Press, Character and Key Release. Key Press and Key Release should give only the description of which physical key on the keyboard has been pressed or released, including modifier keys (shift, CTRL, etc). Currently the Squeak VM uses the "Mac-Roman" encoding to encode which key was pressed or released, which is less than ideal and still differs per platform. The Character event contains a Unicode character. A single Unicode character may have required multiple key presses and even some UI interaction to be composed.

There are three types of hardware keyboard in the world; the US one (104 keys), the European one (105 keys) and the East Asian one (109 keys). These are very similar to each other and based on the PS/2 keyboard. Almost every keyboard in the world is based on one of these hardware prototypes with different printed letters on it.

I've also found that the USB specification (made by Microsoft) has reasonably elegant "scan-codes" that specify the actual keys pressed with no regard for which character is printed on that key. I believe these codes would provide for a much more elegant way of specifying which keys were pressed in the "press" and "release" events than the Mac-Roman keys currently provided by the Squeak VM. Unfortunately, any notion of the original USB scan codes have long been forgotten by the OS by the time the character arrives at the Squeak VM, so the VM or the image will need to map OS-specific event IDs to the equivalent USB scan codes. It is a bit of a roundabout way to do it, but the end result is an OS-independent manner of doing raw keyboard events. Perhaps SqueakNOS can strip away the layers of abstraction and pass USB scan-codes through directly? :-)

The end result is that an application using Subcanvas can either use the character events, or it can use the key press and key release events to roll its own "Input Method Editor". This gives a good level of initial functionality for most languages in the world by using the Unicode character input directly from the VM, as well as a future growth path for implementing new "Input Method Editors" (or games) using the raw key press and release events.

On another chain of thought, I'm considering making Pango and Freetype "libraries" available in SecureSqueak / UGP. If they're provided as a resource such that Subcanvas does not have any architectural dependencies on them, they can be implemented as a "deprecated on birth" resource that will provide necessary text rendering functionality until pure Smalltalk-based solutions can be written. At this stage, I'm a bit wary of just how complex the rendering of multilingual text can be.