Event implementation
Marcel Weiher
marcel at metaobject.com
Wed Nov 1 10:48:10 UTC 2000
> 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
More information about the Squeak-dev
mailing list
|