> From: "Raab, Andreas" <Andreas.Raab at disney.com>

> > How about Unicode?
>
> We are talking about specific keyboard keys here. Key up/down  
events report
> keys the user presses on a particular keyboard.

Sure.  If you want to be really close to the hardware, you should  
probably use raw-codes, however useful those are.

> I don't think Unicode has a  representation for the left and the  
right shift key...

Well, you can always use the "user defined" range (or whatever it is  
called).  Also, I don't think any applications should rely on these  
being distinguishable.  For example, MacOS-X/Cocoa doesn't even  
generate key-events for the shift keys, it generates a  
"flags-changed" event that does not distinguish between left and  
right shift keys.

>and that's why we can
> live without key down/up events (right now they're unused) but not  
without
> the character events.

Hmm, that's a funny distinction.  Does this mean I get several  
different types of events for the same action?  Is this Windows  
specific?  With MacOS-X/Cocoa, a keystroke gets me two events, a  
key-down and a key-up.  Any additional information, such as various  
character translations etc. are provided with those events, instead  
of as distinct events.

> The OS does the mapping for us from the key code[s]
> into the actual characters (e.g., when you use some of those multi-key 
> combination characters such as accents on certain keyboards) so we  
don't
> have to know about these mappings at the Squeak level but can  
still respond
> to whatever we find a good idea (I love the "ctrl" key as fire button). 

Agreed, however, I kind of like having the translation(s)  
accompanying the up/down events.

[semaphore use]

> To no good use. The semaphore is provided for two reasons:
> #1 - indicating to the VM that we want to use the event driven  
primitive
> set.
> #2 - For TRULY asynchronous event notification mechanisms. E.g., if you 
> would run the event processing loop in a different thread than  
Squeak that
> is the semaphore to signal.

That is actually what I am doing.  Cocoa has its own event loop, and  
I just hook into its -sendEvent: message.  While it is possible to  
run your own event loop (and the code is there in the Squeak port),  
I'd rather not.

> For now, this signaling actually hurts more than
> it helps (the explanation takes a bit of time so I skip it for  
now) but it's
> not too bad if your machine is fast enough.

Oh, that sucks.  Can I avoid this without resorting to going  
single-threaded again and running my own event loop?

> BTW, if you've been digging in my sources, please notice that  
there's a call
> to ioProcessEvents() in ioGetNextEvent().

Yes!  In fact, that would have been my next question.

> That call is IMPORTANT - if you
> leave it out you will get an arbitrarily sluggish behavior.

Ahh, that is probably the cause for what I am seeing.  However,  
adding it in doesn't actually change anything, because my  
ioProcessEvents() implementation only does the aiPoll(), it doesn't  
actually look for events.

Why would I get arbitrary sluggish behavior?  Does this also apply  
to the case where OS events are being handled in another thread?

Marcel