multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On Tue, 2010-10-12 at 21:27 +0200, Henrik Rydberg wrote:
> On 10/12/2010 06:53 PM, Chase Douglas wrote:
> > On Tue, 2010-10-12 at 16:31 +0200, Henrik Rydberg wrote:
> >> On 10/12/2010 03:49 PM, Chase Douglas wrote:
> >>> 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.
> 
> 
> There is no argument that client-side grail solves client-side event
> propagation. The argument is whether supporting the linkage between the two
> propagation models is a good idea.
> 
> I appreciate that the solution Peter and yourself have arrived at is navigating
> delicately in a somewhat jungleish environment. However, duplicating the window
> event propagation on the client side may very well be a simpler solution.
> Implementing get_clients() would not be much more complicated, would it?
> Stephen's ideas are starting to make sense to me. :-)

If you went this route, where toolkits and apps listen directly to the
kernel and are assumed to propagate events between them appropriately,
you'll have issues once you start mixing in legacy apps and toolkits
that listen for this data from X.

Also, in order to perform proper propagation between "windows", each
application will need to query the window stack on every new input event
to be sure it is allowed to handle the input.

> The problem I have with passive grabs is that it uses tentative events as a
> solution to the round-trip problem involved in accepting MT events. In my mind,
> tentative events should be used to show something different from normal events,
> something that makes the user understand their volatile nature. In this respect,
> inhibiting pointer motion during two-finger scroll is quite different from user
> feedback during a rotation gesture.

I think we are thinking of two different types of events. The XI 2.1
passive grabbing provides for tentative device events. You are talking
about tentative event actions? Tentative actions are built upon either
tentative or active device events, but we need tentative device events
to be able to potentially handle the same events either system-wide or
at the application level.

> I hope this does not sound too discouraging - I am simply trying to turn some
> stones here. If you already turned them, I am sure you will tell me. :-)

Heh, that's exactly what I'm hoping for, for you to turn more stones. I
don't think any of us would agree that XI 2.1 passive grabs are elegant
or clean. I certainly don't want to help implement them, but them's the
breaks :). Please keep digging if you think you can find a better
solution!

-- Chase