I realize this will need a whats_new entry etc., but I want to first find out whether anyone sees any problem with this approach.
If not, a possible addition would be to add a kwarg to twinx and twiny to control whether this swapping occurs automatically.

LGTM 👍

I think this looks like a fine way to do this.

This is getting close to being ready, based on the present approach, but it raises some questions. The main problem is that the Axes stack order determines which Axes gets the mouse events, and it also determines the order in which Axes are drawn--unless one overrides this with Axes zorder. Typically this is not done, so swapping Axes requires swapping their positions in the stack,and swapping the visibility attribute of their patches. In the second changeset, I added that functionality to swap_axes_order. This will not be the desired result, however, if zorder is being used to determine the Axes drawing order; in that case, for shared axes, only the one with the lowest zorder should have a visible patch.
This fragile coupling between drawing order and mouse event order is awkward and confusing.

This may be a dumb question (I have not dug around in this section of the code recently), but why don't we just raise mouse events for all axes that the mouse is in and let the event handlers sort out if they want to handle the event?

I think that would be even harder to manage; for example, how would you determine what gets displayed in the cursor position readout?
(Travis failures look odd, but unrelated.)

I would want display the location inall of the axes that the cursor is in.

I think that could be done tacking an extra dict on to the canvas object and makingmouse_move a bit smarter.

On 2014/05/04 11:14 AM, Thomas A Caswell wrote:

I would want display the location in /all/ of the axes that the cursor
is in.

That would require a different scheme for fitting them into the window,
and for labeling them. The readout region would have to expand
vertically to make room; one would want them in a stack. All doable,
but it would mean changing all interactive backends. I agree that it
might be a nice improvement.

My thought was much lazier, either ask the axes object their gid or just label them sequentially and keep them all on one line:

ax1: format_coord(...) | ax2: format_coord(...)

I don't think this would require touching anything outside of backend_bases.py

I'm reluctant to include this in 1.4 because it sounds like you might have a better approach,@tacaswell . I don't want to introduce an API change unless we are confident that it is what we want for the long term.

Fair enough. I re-tagged this issue.

It looks like you could useax._shared_x_axes.get_siblings(ax) andax._shared_y_axes.get_siblings(ax) inmouse_move and add messages for all siblings.

Looks like it's time to abandon this one.