about events

Ned Konz ned at bike-nomad.com
Fri Nov 15 16:42:12 UTC 2002


On Friday 15 November 2002 07:40 am, Chris Burkert wrote:

> > Should Morph>>on:send:to: be replaced with Object>>when:send:to:
> > and the trigger message ? If yes I could take a look at this.
>
> May I ask the upper Question again. Perhaps you missed it in the
> last days full of giant steps. I hope it's not a stupid Question,
> but I'd better ask instead of leaving it.

Hi Chris,

I saw it but wasn't sure that I had an answer. So 
(uncharacteristically for me) I stayed quiet. I was hoping for 
Andreas or someone to answer.

> Do we need the Morphic EventHandler or could this be solved with
> events in Objects trigger mechanism ?

Good question. As you know, the default EventHandler has pre-defined 
slots for various different kinds of events. Which makes it 
impossible to add new kinds of events without subclassing the 
EventHandler. Still, it'd be pretty easy to come up with an 
RealEventHandler subclass that uses the events mechanism, and to try 
using it instead.

One notable improvement would have to do with the implementation of 
#on:send:to:withValue:. Right now you can only have one of these 
active (if they have different value parameters), because the "value" 
parameter is stored in the EventHandler's valueParameter instance 
variable. Of course, all the cases where this is called in the image 
multiple times use the same value parameter. Still, I've wanted to be 
able to use this for other things (it could help, for instance, in 
reducing the number of Button classes).

It also would allow doing multiple things on the same event. So you 
could have a button that did several things.

> I've took a look at both and I would say the trigger mechanism is
> more elegant. Because of the changed interface in 3.4a we could
> design a new, possibly faster Morph for 3.4. Of course that's much
> work. What do you think ?

I don't think it'd be faster, but it would be more flexible (and might 
save memory as well). Right now, what happens is that the 
EventHandler holds on to a recipient and a selector (kind of a 
flattened MessageSend) for each event defined. So we just do a 
perform every time an event comes in. The new event mechanism also 
does a perform, and also has to go through one (or two?) 
IdentityDictionary lookups to find the actual MessageSend(s) that 
have to be perfomed.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE




More information about the Squeak-dev mailing list