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

Cheers,
   - Andreas