← Back to team overview

multi-touch-dev team mailing list archive

Re: A new release of xi 2.1 + utouch stack in xorg-unstable ppa

 

> >> At this time I would like to receive any issues or bug reports on this
> >> mailing list. We will transition to launchpad for bug reports once the
> >> work is in Ubuntu proper, but due to things still being in flux I think
> >> reports are better here for now.
> > 
> > There is an important difference in the handling of prolonged gestures
> > in this environment, which seems to imply that not all basic
> > application gesture needs can be met with this approach.
> > 
> > With the maverick X drivers (synaptics and multitouch), it is natural
> > to position the cursor with one finger, and then add another finger to
> > scroll a bit, life one finger to position the cursor again, and so
> > on. The same goes for zooming, where one first positions the cursor,
> > then zooms at that point.
> > 
> > With the new natty XI2.1 packages, the gesture engine releases control
> > over a touch based on a timeout, passing it on to the application in
> > such a way that the modus operandi described above no longer is
> > possible. In practise, one might need to view the server-side
> > recognition as dedicated to system gestures, and instead reimplement
> > the current application behavior on the client side.
> 
> It's not confined to system gestures, but to gestures that are clear
> from the start. For example, you can still have a two finger drag
> gesture, but you must initiate it immediately. It can't morph into a two
> finger drag from a one finger drag, for example.

True.

> You have been a proponent of trackpad position then scroll then position
> based on the number of fingers. I believe this comes from how OS X does
> things. I think there are a few reasons why OS X can handle this, and
> why it doesn't fit in our system as it is:

Actually, it is not confined to OSX at all, but is a very common
behavior for anyone with two-finger scrolling enabled on their
machine, which amounts to millions of users.

> 1. We have been of the mindset that a touch stream from X must only end
> when the touch has physically ended. Another way of stating this is that
> any client using the touch stream events must either use the entire
> physical stream or none of the stream.

I think we need to turn this argument upside down - the user is right,
the technology is wrong. ;-)

> 2. OS X performs two finger scroll recognition on the server side. We
> have been of the mind that all multitouch gestures should be handled
> client side.
> 
> Because of 1, we cannot start moving the pointer with a touch stream,
> and then end the touch stream when a second touch begins and we start
> performing a scroll. I believe OS X skirts 1 by checking if the window
> under the cursor wants touch events, and if not it will send scroll
> events as appropriate. In essence, I believe OS X is special casing
> scrolling.
> 
> Maybe we should be special casing scrolling too, but I'm not quite
> convinced. I would rather have the window system be "dumb" and handle
> things like scrolling on the client side. This would prevent lock-in to
> a poor system only fully understood in the future (just like we have
> with scroll buttons in X today). However, it may mean that we lose the
> ability to have position then scroll then position based on the number
> of fingers, as OS X does.

I think special-casing this makes a lot of sense, considering pointer
movement can be clearly identified as input focus modification, which
is conceptually different from touch drags. Mark's suggestion will
most likely work satisfactorily.

Thanks,
Henrik



References