[squeak-dev] Re: EventSensor questions

Andreas Raab andreas.raab at gmx.de
Thu Feb 12 20:30:20 UTC 2009


Igor Stasenko wrote:
> Well, a mouse event is a mouse event, you can't treat it differently. :)

Oh, but you can! Just look at #swapMouseButtons. More interestingly 
along these lines is that there are synthesized events (mouse 
enter/leave for example) that all UI frameworks have but that aren't 
part of the "kernel" event types. So in order to make this fit "your 
framework" you'd have to munge with the kernel types. That's why I'm 
saying that unless you are insisting on a single framework there will 
always be differences in how the event structures are modeled and a 
one-size-fits-all-approach isn't very helpful.

> This is why i thinking that even wrapping event buffer by specialized
> event subclass could be helpful.
> I.e.
> 
> event := KernelMouseEvent from: eventBuffer.
> 
> so, then you can write:
> 
> event isMouseEvent
> instead of:
> (eventBuffer at: 1) = EventTypeMouse
> 
> The idea is to promote most basic event types from Morphic-Events to
> Kernel-Events.
> So then another framework could reuse them as a base, without poking
> in raw event buffer.

Understood. Yes, this could be helpful for some purposes. The reason why 
I don't like it is that since a UI framework will require its own events 
to begin with (see above) why clutter the kernel with artificial 
distinctions about event types that the kernel really doesn't care 
about? What good would it do Morphic or MVC or Tweak if you were to add 
these events? Given the tiny interface between the sensor and its 
clients[*] it seems like a complication with very little benefit to me.

[*] Never mind all the abuses of Sensor.

> It is also useful in a way, that in case if we need to alter event
> handling logic in future VM, then we will have a much less places to
> visit in image to adopt these changes.

That's a much better argument and one of the few I'd be willing to 
accept from what has been said so far. The other one is actually 
documentation - it can be quite difficult to wade through tons of 
constants trying to figure out which bit corresponds to what field.

> The custom framework could always adopt these events for own need , by
> encapsulating them with own event types/whatever.
> 
> I just think that events deserve to be encapsulated into a
> well-defined objects at kernel level.
> In current state it looks like, that if you have a socket primitives,
> but have no Socket class which enables to work with them in a
> meaningful way, so each user of sockets needs to deal with primitives
> directly and write own data handling logic :)

This on the other hand is not a very good argument since there is only a 
single user of socket primitives (Socket) and there aren't multiple 
competing types of Sockets. Following this logic you might as well 
create Morphic events right in Sensor.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list