I note that the existing x-/y- modifiers do not really work when using my laptop's touchpad¹, but this proposal does work nicely 👍

This is an interesting concept, though I was a bit surprised at first. Is there any precedence that other programs use this approach?

Also, would it be a good idea to give some sort of visual aide, with the goals (i) to make it clear that something special is going on and (ii) give an indication of the area the mouse has to be in so that the special handling applies? e.g. something like marking the region:

Matlab has similar behavior. Could implement something similar where the lines at the edge indicate the region the mouse needs to be in?

The range marker is a good visualization to indicate the difference. Though, I would like to additionally keep dashed lines as an extension of the whiskers, because that helps to ensure relevant data points are included.

That said, all the visual changes would need refactoring and backend-dependent implementation as currently all visualization is done viaRubberBandBase and that does only cover the rectangle without the ability for further modification.

Example of whiskers and dashed rectangle using QtCairo and QtAgg backends. The width of the whiskers represents the region the mouse needs to be in for single-axis zoom.

Excuse the lack of mouse pointer in the screenshot.

Backends so far

• tk
• gtk (unable to test on my machine, but code is written)
• Qt
• wx
• WebAgg
• MacOS

All backends have been updated. As previously mentioned, I was unable to test gtk on my machine, but I have tested all other backends. Several other fixes were also included:

• Ensure that the zoom rubber band is dashed in all backends (it was not in WebAgg).
• Fix the Tk rubber band: the implicit black line colour was not working, so it was set explicitly instead.

All backends have been updated. As previously mentioned, I was unable to test gtk on my machine, but I have tested all other backends. Several other fixes were also included:

• Ensure that the zoom rubber band is dashed in all backends (it was not in WebAgg).
• Fix the Tk rubber band: the implicit black line colour was not working, so it was set explicitly instead.

Could you move them out into a separate PR? It makes reviewing this PR simpler if we don't have multiple topics.

This PR is a good prove-of-concept and from a first glance feature complete - thanks for implementing all the backends!

We still need to think about the architecture and how to bring it into the main library. As is, thedraw_whisker method is an API change that will break third-party backends. We'll have to decide

• API design: whether that method is the right approach (other alternatives could be integrate it into the rubberband, or start a more general approach for drawing some primitives in the backend in the anticipation that we will have more interactivity (e.g.PoC: GUI-native crosshair cursor #30516).
• API compatibility: As is this is breaking 3rd party backends, which is a no-go. We could either work around this through special-casing (test if the method is available in the backend) or go for a more structured approach of API versioning[ENH]: Backend versioning #30559.

The bugfixes have been separated into#30560

Regarding third-party backends, I don't fully understand how these would break. The emptydraw_whiskers method in the base classNavigationToolbar2 appears to address this concern. During development, even before integrating the whiskers into a new backend, the backend would continue to function, albeit without displaying the whiskers.

lib/matplotlib/backend_bases.py:2938

Attempting to use theipympl backend in Jupyter leads to the following behaviour:
no whiskers are displayed, only a zoom box. There appear to be console messages indicating that there is no handler for thewhiskers event, as it is a subclass of the WebAgg backend, which calls this event.

Tested withmplcairo third party backend and got the following results

• mplcairo.macosx: Whiskers inherited from mpl macosx class
• mplcairo.qt: No whiskers drawn, box only. No errors thrown
• mplcairo.wx: Scaling is off on my machine, whiskers still work though
• mplcairo.tk: Whiskers inherited from mpl tk class
• mplcairo.gtk: Whiskers inherited from mpl gtk class

Since I got gtk working on my machine, here's a screenshot of the feature with each builtin backend. Have also tested the cairo backends with the same results.

Having a more thorough read of the issues you've linked, I think we can consider the following implementation:

Adraw_line() method be implemented for each backend, taking in color/stroke/dash parameters.draw_rubberband() anddraw_whiskers() could then make use of this method in a backend-agnostic way.
Additional interactions (i.e. the crosshair) could then make use of thedraw_line() function and not require backend refactoring.

I see that this could have some ramifications on third party backends, as it could breakdraw_rubberband() as they won't have adraw_line() method (unless subclassed from a mpl backend). Somewhat uncertain about the versioning system, is this for third party backends only? or is there concern that mpl native backends could misalign with the package itself?

Somewhat uncertain about the versioning system, is this for third party backends only? or is there concern that mpl native backends could misalign with the package itself?

native backends could partially misalign, i.e. an intenal backend doesn't have to be on the newest version of the API, but of course it must have a version that is supported, i.e. if at some point matplotlib supports backend versions v1 and v2, then every internal backend must be one of these versions. For example it would be permissible if we don't implement a new API for all backends right away.

see that this could have some ramifications on third party backends, as it could breakdraw_rubberband() as they won't have adraw_line() method (unless subclassed from a mpl backend).

For the time being, I would leavedraw_rubberband() it's working as is. We can refactor that later when/if backends have gained more general drawing capability.