On 01/26/2015 09:49 PM, Jonas Ådahl wrote:
I'd say either this (2fg swipe doesn't exist), or generate both scroll
events and 2fg swipe gesture events for 2fg swiping movements. Either
the 2fg scroll feature "eats" its corresponding swipe gesture feaure
and we ignore its existance, or we emit multiple independent events for
the same input.
I'm don't really understand *why* we wouldn't want to emit multiple
events for the same input, aside from that it might end up in shoot foot
scenario implementation wise. And ideals maybe.
I think you *must* support this or you will not be able to add new
gestures in the future: if you add a new gesture and it started
producing a new event and stopped producing whatever it did before, than
any client that does not know about the new gesture would just not
respond to the event. It would be preferable if the client continued to
act like before.
I think the way to do this is to add something to the event to indicate
that it is "final". This could possibly be a different set of event
types or another field added to the events. Events would be sent in
order from "highest" to "lowest".
A "swipe" might send events (once the fingers are moving fast enough
that it is a swipe) like this:
- Swipe down
- Scroll down
- Drag two fingers down
- Drag finger 2
- Drag finger 1
Some gestures take some time to recognize, so it may have to defer
sending events until it decides. For instance if it needs to decide
between swipe and scroll it may not send anything until it figures out
how fast the fingers are moving. I think this is the way it is working
now anyway, right?
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
