On Tue, 2010-10-12 at 16:31 +0200, Henrik Rydberg wrote: > 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.
There must be a way to propagate input among various "windows" still. Different windows from different applications have differing toolkits and event propagation. The common interface between them all is XInput (or core X protocol). So the most straightforward path seems to be to extend XI for MT support. > > 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. This sounds like another client-server model, but with a different server now. I'm not sure how this solves the event propagation issues with client side toolkit rendering, and I only see it duplicating what could be done more naturally in the window server input layer. -- Chase _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
