> 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