This also collides with #16931

From a very quick look, it seems like on the GUI toolkits side (especially gtk, from which we got the event names (button_press_event, etc.), but also the others) typically have a single touch_event handler, and then let the single callback differentiate based on some flag present on the event; unless there's a strong reason to do things differently here I'd suggest also sticking to just touch_event + flag-on-the-event-object on Matplotlib's side.

It may also be nice to review how the various GUI toolkits handle multitouch (which is relevant for zooming), keeping in mind that we'd like to keep the API the same across all backends (except for the guiEvent attribute which refers, well, to the native event). Again, from a quick look:

• qt send the actual touchpoints (https://doc.qt.io/qt-5/qtouchevent.html#touchPoints) grouped in a single object. Alternatively, qt also appears to have the higher-level gesture API (https://doc.qt.io/qt-5/qgestureevent.html).
• js appears to also expose low-level touches (https://developer.mozilla.org/en-US/docs/Web/API/Touch_events/Using_Touch_Events), but not higher-level gestures. But perhaps we can use e.g. https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events/Pinch_zoom_gestures?
• wx synthesizes a single ZoomGestureEvent (https://wxpython.org/Phoenix/docs/html/wx.ZoomGestureEvent.html#wx-zoomgestureevent) without low-level touchpoint info.
• gtk sends independent "event sequences" for each touch (https://developer.gnome.org/gdk3/stable/gdk3-Events.html#GdkEventMask), which I guess we can take care of grouping together? Likewise gtk also appears to have the higher-level gesture API (https://developer.gnome.org/gtk3/stable/GtkGesture.html).
• tk doesn't seem to handle touch events at all?

So I guess another question would be whether to expose at all the low-level touch events or the higher level gestures in Matplotlib (after all the actual event handlers may be easier to write against a gesture API?)

Thanks for taking the time to look over the various touch event options across the backends @anntzer. I definitely agree with the idea of standardising on something which is consistent across the backends, and it isn't a given that the JS approach is the one we should necessarily opt for.

In terms of implementation, it doesn't change a huge amount I think - we just need to make a decision and then it can be implemented. How would you like to proceed with making the decision - I definitely don't have enough experience of touch events across backends to be able to make an informed decision that doesn't risk precluding certain types of touch event handling.

I don't actually know anything about touch event handling other than what I listed above (which basically just comes from some quick googling...). So I don't have much to contribute on the API design side. However, once again I think that even if you don't provide implementation (of whatever API you choose) for all backends, it would be nice to at least be sure that everything you propose is at least in theory implementable across them.

I'm also not experienced with touch events. But from a usability point of view, a gesture API is simpler to use. And it's simpler to get right because it's a higher level abstraction that's less dependent on the low-level API of the frameworks (we can wrap that). We can always add an additional low-level touch API later if needed.

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.