From: "Raab, Andreas" Andreas.Raab@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