I like that you're sending key down and up events. However, I don't fully understand what they're supposed to be. Are you looking to have raw keycodes (OS specific)? Or just the same old (pre-mapped) codes from the VM?
Depends on the interpretation of the character code. For now, I'm assuming that every key is reported in current Mac Roman encoding. This is mainly for compatibility.
I find the VM's mapping of keys to be a weak spot of the current implementation. There are a number of keys I just can't use, or that don't work the way I'd like (for instance, I don't seem to have a forward delete key in Squeak).
There are plenty of ways in which this could be handled. Such as using character codes > 255 for encoding these special keys. I haven't put any effort into this because I figure somebody will hopefully assemble a list of the keys we want to have reported which we could then just define as "the standard".
And I can't get raw key information (for instance, to differentiate between a keypad "1" and a main keyboard "1").
Again, this is an issue that should be handled using extended character codes. One could for instance define that the lower eight bits of the character code represent the character to be generated if a client doesn't really care for a more specific representation. E.g., if you report the main keyboard "1" as 16r31 and the keypad "1" as 16r131 then you could extract the actual character by just extracting the lower bits. If you're interested in more specific information you could have a look at the numeric keycode to distinguish between the two.
I wonder, also, what happens on key down events? Is there both a key down and a character event generated?
Yes. The idea is that the VM reports: - a single key down event - possibly multiple character events (if the key is pressed long enough to activate the OS autorepeat) - a single key up event So if you press a key shortly, you'll get keydown, character, keyup. If you press it for a longer time you get keydown, character*, keyup.
And what about keyboard auto-repeat? It's often distinguishable from the initial key press, at least at the OS level. You only have key down and up (as well as cooked char) events.
This can be handled by examining the sequence of key events generated. It might well be possible to cover this issue at the VM level but I'd rather leave it to the ST code itself to deal with this matter.
I'm still trying to figure out how to prevent the C support code from creating raw oops (another thing I don't like is that with Tims implementation you have to create oops yourself).
Why not just pass a ByteArray to the primitive and let it stuff in raw bytes instead of an Array (which you'd have to create oops for)?
I don't really like ByteArrays here - too much interpretation imposed to the ST side where we really only need a handful of Integers. Note that I don't mind creating a couple of SmallIntegers from within the VM; the thing I don't like is that the C support code (e.g., a VM porter) has to know how to create ST oops. This can lead to fatal and hard to track down errors (such as when you have to mask the time stamp for matching the VM's assumption about what number of bits is reported by ioMSecs) so I'd rather pass out a plain C structure which the C support code fills in and the primitive code in the VM will map these into the appropriate ST representation.
- Andreas
squeak-dev@lists.squeakfoundation.org