On Fri, Feb 13, 2009 at 9:30 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

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



If I had written EventSensor, this is how I would have done it because it
makes code a lot more readable. I would make this event wrapper class only
support the actual events coming from the VM; it is still the responsibility
of the UI framework to synthesize the extra events.

The reason I asked my original question is because I'm working on Subcanvas
(http://gulik.pbwiki.com/Canvas), which is a graphics and events API; it is
a high-tech replacement for the Canvas class.

Gulik.
-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090213/948ae31f/attachment.htm