[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
|