Twin axis message coordinates

[OceanWolf]

When using twin axes such as that in http://matplotlib.org/examples/api/two_scales.html only the coordinate of the twinned axis displays in the message area x=... y=.... This I find annoying when trying to read of data and find I can't.

I would expect the message bar to say something like x1=... x2=... y=....

Not sure when this should get fixed, it feels like it should wait until MEP22 gets merged, but thinking about implementation, I wonder if we should use the axis label instead of xn, yn, and if we do that, then perhaps we should allow for a short label for message area and a long label to place next to the axis, and so I wonder if this can get achieved without a break in api, if it can't then it should go in with the color overhaul for 2.0.

Thoughts?

[efiring]

Axis bar space is limited. I don't think using axis labels is feasible or desirable in general.
We are adding bug fixes to color_overhaul, but the idea was to restrict anything beyond bugs and style to master, for a subsequent release.

[OceanWolf]

Yes, the limited space crossed my mind, one of the reasons why I suggested waiting until after MEP22. Aside from making this easier to implement; @fariza tells me that to make room for more tools in the toolbar, the message area will go on a separate line all to itself for every backend, atm this only happens on some of the backends.

In terms of axis labels, the problem I see for the user with just x0, x1, etcetera, comes from remembering which number refers to which axis. For example take a figure like http://www.whoi.edu/beaufortgyre/dispatch2008/images/89CTD%20profile.jpg I would imagine the user would give short labels to the axes so that the message area says something like T=28.0, S=37.0, depth=30.4. Personally I find this a lot clearer then x0=28.0, x1=37.0, y=30.4, especially as other people then the original coder may use the programme. Of course both serve as an improvement to the x=37.0 y=30.4 we have at the moment ;).

[u55]

👍 I would also very much like this feature. It would be nice to not have to call ax.set_zorder(1) on the host axes and then replot if I want the mouse to report the position in the host-axes coordinates instead of the twin-axes coordinates. Most of the time, I want to know the position in both coordinate frames.

Furthermore, the current behavior is not consistent between pyplot.subplot and mpl_toolkits.axes_grid1.host_subplot. The latter automatically reports the mouse position in the host coordinates, even after creating a twin, and setting the zorder of the twin axes does not bring the twin to the forefront for mouse events.

[tacaswell]

Getting this to work would require an overhaul of how the event system propagates mouse events, currently the top Axes eats the event. If you really need both you can define a custom format function which knows about the other axes and does the correct transforms to get out both locations.

@efiring and I had a discussion about this in another issue, but I can not find it right now.

[tacaswell]

This is also related to #3989 which allows artists to tack extra information onto the message string.

[OceanWolf]

Ooh, overhaul, I like the sound of that, something for after MEP27 and MEP22

Also I think it should tie in with #3984

[fariza]

Even without the overhaul of the events, it would be possible (fairly easy) to modify backend_tools.ToolCursosPosition of MEP22 to extract the information of the twin axis.
I am not saying It will be done or add it, I am just saying that it can be done.

[OceanWolf]

@fariza Agreed, I don't think MEP22 should get cluttered up with extra features, they should wait until MEP22 lands.

I opened this up as an issue just so that a) I don't forget this as an issue for later, and b) start the discussion on this bug/missing-feature ahead of time.

[github-actions]

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

[anntzer]

See #25556.

[github-actions]

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!