[RFC libinput] Add an API for touchpad gesture events

[Hans de Goede]

Hi,

On 23-01-15 14:57, Hans de Goede wrote:
> Hi,
>
> On 23-01-15 14:53, Jonas Ådahl wrote:
>> On Fri, Jan 23, 2015 at 12:18:01PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 23-01-15 05:21, Peter Hutterer wrote:
>
> <snip>
>
>>>>> +double
>>>>> +libinput_event_gesture_get_absolute_x(struct libinput_event_gesture *event);
>>>>
>>>> this is a bit inconsistent with the other API where absolute_x returns a
>>>> value in mm. I think we should do that here as well and provide
>>>> get_absolute_x_transformed - callers that need it in relation to the
>>>> touchpad size can just provide 1.0 as width/height.
>>>
>>> I don't think mm is really interesting on a touchpad, and in many cases if we
>>> say this is in mm we would be lying as we do not know the exact dimensions. I
>>> see using (fake) mm-s here and then having users call get_absolute_x_transformed
>>> with 100 or 1.0 to get the percentage they very likely want from the beginning
>>> as just adding baggage without any gain.
>>>
>>> The intend behind these absolute coordinates is for them to be used in e.g.
>>> a virtual desktop switching animation when switching using a swipe, this way the
>>> user can start a swipe, see the new virtual desktop, realize it is the wrong one
>>> and abort, or if it is the right one continue, and then past say 2/3ths of the
>>> touchpad the animation will show the new virtual desktop locking into place, and
>>> the user will know he can stop swiping. Notice the key thing here is the swipe
>>> reaching the 2/3th threshold, not some magical amount of (fake) mm-s.
>>>
>>> Carlos, Jonas what do you think ?
>>
>> That would still be possible with a mm based absolute coordinate as we
>> can retrieve the physical dimension of the touchpad with
>> libinput_device_get_size(). And as long as the driver gives us reasonably
>> correct physical dimension data, the mm-s aren't fake; or do you mean
>> most drivers lie to us? It'd be better also not to have it simply 1.0 x
>> 1.0, as that'd make making a circle on the device result in an ellipse in
>> the API.
>>
>> Since we already do mm-s everywhere, I don't see it that horrible to not
>> drop that information here in order for some smart future usage, or at
>> least consistency.
>
> Ok, I'll change this to mm for v3 then (just send v2 addressing the other
> review comments and adding a core implementation).

So I've been thinking more about this and I'm still not fully convinced, let
me explain.

The problem is that the edges where a swipe begins and end may vary based
on config settings and even per swipe.

e.g. If a clickpad is using softbutton areas on the bottom, and the user
swipes up, the swipe gesture will not start until the fingers have left the
bottom button area, because before that they are seen as fingers resting to
click the buttons, so for that gesture the bottom edge would be the top edge
of the button area.

But if the user swipes down, he can use the bottom button area because fingers
are only not counted as active there, when they've started there.

Now we could always only count the non soft-button area as the area to which
absolute gesture coordinates should be compared to see where on the touchpad
the gesture is, but what if clickfinger is enabled, then there is no soft
button area?  Then what if the user changes the clickfinger setting ?

A solution to this would be putting the relevant area in the gesture event,
and documenting that it may differ per event and that users should always
compare absolute coordinates to the area relevant for that device. But this
does not sound like a very nice API to me, and also makes me worry about the
wayland protocol.

All in all this sounds very much NOT kiss, and I'm a big fan of kiss, so I
really believe that the initially proposed 0.0 - 1.0 scale is much better,
it already gives apps way more info then the current gtk and mac os x api-s
do, as those both only give deltas, while turning all the above into an
implentation detail, rather then something which we need to explain in API
docs. The above is exactly why we want to do the gesture handling inside
libinput in the first place, and exporting absolute event data in mm, unhides
all the nitty gritty we're trying to abstract away in the first place.

Regards,

Hans