Repository navigation
ColorbarAxes is an imperfect proxy for the Axes passed to Colorbar #20479
Description
Activity
Thanks @richardsheridan we should sort this out, but do you have short scripts that cause problems without requiring interactivity? I'm a little confused, without looking carefully, why the methods have not been passed to the parent. That was certainly the intent.
So just to be clear
fig, ax = plt.subplots() pc = ax.pcolormesh(np.random.randn(30, 30)) cb = fig.colorbar(pc, ax=ax) cb.ax == ax # returns False
has always returned False. ax is the axes that the colorbar is placed, not the parent axes (ax) that made room for the colorbar.
It is also true that cb.ax.set_xlabel == cb.ax.inner_axes.set_xlabel is False, but they do the same thing.
What is incorrect is that the colorbar axes never gets added to the axes stack on the figure, so it can't register events. Adding it to the figure axes stack makes it recognize axes_enter_event and axes_leave_event. It also does the right thing for button_press_event. What it fails to register is a pick_event properly. However, I'm confused, because I could not get a pick_event to register anywhere on the canvas, so maybe it is just my backend...
I think I have a patch for pick_event, but it would depend on cb.ax correctly getting added to the artist tree, which, as you note, isn't the case currently.
Bug report
Bug summary
Before the refactor, one would set colorbar axes to be pickable with colorbar.ax.set_picker(True). Now, it is necessary to use the undocumented colorbar.ax.inner_ax.set_picker(True). Likewise, with motion notify events, MouseEvent.inaxes is not colorbar.ax under any circumstances, it always is colorbar.ax.inner_ax.
But, this is not really about events so much as the fact that Colorbar(ax).ax is ax == False and all methods of colorbar.ax are actually bound to a different object, namely colorbar.ax.inner_ax, so they are acting on surprising, hidden state (from a user's perspective).
We could work around the events issue, but I feel like there would be an ongoing stream of bug reports without a comprehensive fix. On the other hand, I definitely don't want to revert ColorbarAxes entirely because I really like the improvements that it enabled.
Code for reproduction
Please see #20471, which this issue blocks (in my opinion).
Matplotlib version
cc @jklymak