multi-touch-dev team mailing list archive

[Henrik Rydberg <rydberg@xxxxxxxxxxx>]

On 10/12/2010 03:49 PM, Chase Douglas wrote:
[...]

>> For this particular example, since the regions are listening to different
>> gestures, there is actually knowledge available on the server side as well, so
>> the combinatorial explosion does not seem to enter here.
> 
> This is the real issue: the server does not actually know about these
> regions. In old school toolkits, each widget was a separate X window.
> Modern toolkits don't do this anymore; instead, they have one X window
> for the overall "window" and they draw all the widgets themselves. The
> server doesn't have any information about where any widgets are in
> windows anymore.


Alright, I see you point. So given that we want to rebuild the role of the
server on the client side, for good reason, it seems fair to ask why we want to
have window-based touch propagation like in the proposed XI2.1.

> Going along with this, event propagation for widgets in a "window" is
> performed in the toolkit. When using modern toolkits, X event
> propagation is only used to propagate events between application
> "windows" on screen.
> 
> (Here I use quotes around "window" to refer to what a normal user would
> call an application window, in contrast to the X definition of a
> window.)
> 
> This leads us to the gesture recognition mechanism Peter and I have been
> discussing. Since we can't perform gesture recognition in the server, we
> have to potentially perform recognition twice: first at the system-wide
> level, then potentially at the application level if no system-wide
> gestures were recognized. One method for doing this is XI 2.1 passive
> grabbing.


It seems to me another solution would be to route the events directly to the
client side and use a more modern event propagation model.

Cheers,
Henrik