[Wayland-bugs] [Bug 99415] RFE: Need way to report start of finger scroll

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99415

--- Comment #7 from Carlos Garnacho Parro <carlosg at gnome.org> ---
(In reply to Peter Hutterer from comment #6)
> I guess the main issue I have with this is that we can't drop the "scroll is
> 0 on stop" without breaking backwards compatibility, so if we send a scroll
> stop event, we'd be sending the same information twice and guarantee that it
> always gets ignored. Leaving it out would result in perceived asymmetrical
> event stream. That's a bit unfortunate.

Absolutely, but it's just unfortunate :), once a compositor moves to the newer
event to trigger kinetic scroll, a 0-distance axis event would be transparently
ignored.

> 
> But otherwise, it'd be a LIBINPUT_EVENT_POINTER_AXIS_START and
> LIBINPUT_EVENT_POINTER_AXIS_CANCEL, sent only for some pointer sources. The
> former is relatively trivial, the latter is the one that needs the detailed
> work to avoid breaking backwards compatibility.

I find those names a bit confusing... Not sure if I'm getting the equivalences
right, but on AXIS_START the client is supposed to stop kinetic scrolling,
while on AXIS_CANCEL it does start it?

I guess it's the word "cancel" what troubles me, as it implies something that
can be easily mistaken for its counterpart. I think AXIS_START/AXIS_END are
more symmetric and have less connotations about the effect they're meant to
produce. It still doesn't sound entirely alright for the times they're emitted
unpaired (eg. before 2fg gestures), the oddity might be solved though if we
ensure to emit both start+end before handling it as a gesture.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20170117/2d0910d9/attachment.html>