Ginn should subscribe only to gestures requested

The correct solution is to subscribe to two finger scroll events only on direct touch devices. Currently, the code subscribes to all reasonable gestures on all devices. It needs to subscribe only to the gestures that are listed in the wishes file and only on the applicable device types for those wishes.

Chase, what's the level of effort needed to fix this? Can we get a fix done in time for Natty?

Quite a bit of effort will be needed. I don't think it is reasonable to expect a fix in time for natty. We're talking a pretty large code change that will affect all of input handling for many trackpad devices and all multitouch devices.

So... to be clear, though, the big issue is user experience, right? Trackpads will get the opposite motion that they are used to getting? It doesn't break 2-finger scrolling in the sense that the system no longer has functional 2-finger scrolling, correct?

As it is now, that is correct. However, there are a few options which seem obvious but upon further examination are unworkable:

1. Invert the scrolling for indirect devices. This is probably the sanest and easiest way to do things. However, this would override all configuration of the scrolling in the mouse preferences. For example, it would force two finger scrolling even when the user has disabled the functionality. It would also have its own unconfigurable speed, separate from what is configured in the mouse preferences.

2. Filter out gesture events occurring on trackpads. This will break all two finger scrolling because the scrolling will be "caught" by grail as a gesture and not be processed by X as a traditional scroll event. Essentially, two finger scroll events would be dropped on the floor and discarded without anyone handling them

This leaves us with the complete solution outlined in comment #1, which will take more time than we have available at this point for Natty.

Great, that was a very lucid explanation -- thanks.

This leaves one question in my mind: how do we ship ginn in Natty, given these new findings?

Mark, what are your thoughts?

The attached patch will make it so that only gestures used in the wishes file are subscribed. It determines the type of gesture based on the triggers used in each wish (as per the man file). I could not find a better way to determine the gesture type since the "Gesture Name" is not actually stored (should either the name or an ID be stored for easier checking?).

I have not checked for applicable devices. I don't think this is completely necessary. If the user would like to subscribe to two-finger drags then they should be able to, regardless of the touch device. On the other hand, a tablet/laptop user may want certain gestures for their touchscreen and different gestures for their track pad. How should we account for this?

One thing I noticed and had a little trouble with at first was that application-specific wishes are stored in a separate structure from global wishes. I think that global gestures should be stored in the same apps structure with its appName being NULL. This is just a thought, and I'll wait for feedback before adding this as a bug.

Stephen, I see that you changed the status to Fix Committed then back to In Progress. Is the issue resolve? Or if not, what is the next step to be taken?

I'm keepin g this bug open because scrolling is still inverted for some device types. The wishes should allow for specification of device types and possible for axis inversion.

Hi i implement this you can see in the related branch you can compile the source code of GIR
and use it in the branch page i describe how to do that

this branch full do this ~bijanbina/ginn/GIR

A merge proposal was made for this bug but not yet committed to theginn project. I'm reverting the status appropriately.

The attachment "Determines which gestures are used and selectively subscribes them." of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]