2009/2/12 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> When you have a multiple host windows using hostwindowplugin, we need
>> to dispatch events to a host window first, and then handle them with
>> any framework, which is bound to that window.
>> For this means, the role of Sensor will primarily to poll events from
>> VM , and convert them to events from raw byte array.
>> Next, it should dispatch an event based on window id, and then window
>> should push it farther to whatever listener it have to.
>
> Right. That's what I meant by having a dispatch table that maps window IDs
> to event queues. In which case EventSensor would push the event into the
> queue that corresponds to the index and whatever wants to handle events for
> a window just pulls it out of the queue and processes it.
>
>> The event handling logic could be different, from what i described,
>> but anyway, i would love to see, that there is no other classes in
>> system, which need to deal with raw event buffer except EventSensor.
>> This should help a lot in code clarity & reducing complexity.
>
> I thought that too, but it turns out in practice it doesn't work unless you
> have one and only one UI framework. There is always custom information that
> is useful to be passed along with the event plus there are differences in
> how different frameworks want to model event hierarchies etc. I find the raw
> event buffer the most useful entity to pass along because you get all the
> information the VM had at that point and you can derive whatever state is
> relevant in your application. In fact, we've had many difficulties by the
> intermediate layers (Morphic in particular) making the original data
> inaccessible and had several problems because of it (for example
> button-swizzling etc). I think the end-to-end principle also holds in UI
> frameworks ;-)
>

Well, a mouse event is a mouse event, you can't treat it differently. :)
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.

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.

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 :)

> Cheers,
>  - Andreas
>



-- 
Best regards,
Igor Stasenko AKA sig.