importnumpyasnpimportmatplotlib.pyplotasplt#from matplotlib.backend_bases import MouseButtondefpick_fn(mouseevent):ifmouseevent.inaxesiscolorbar.ax:print('pick\n\nPICKKKKKKK')print(mouseevent.ydata,mouseevent.button)defmotion_fn(mouseevent):ifmouseevent.inaxesiscolorbar.ax:print(mouseevent.ydata,mouseevent.button)passfig,ax=plt.subplots()canvas=fig.canvasarr=np.random.randn(100,100)axesimage=plt.imshow(arr)colorbar=plt.colorbar(axesimage,ax=ax,use_gridspec=True)# helps you see what value you are about to set the range tocolorbar.ax.set_navigate(True)canvas.mpl_connect("motion_notify_event",motion_fn)colorbar.ax.set_picker(True)canvas.mpl_connect("button_press_event",pick_fn)plt.show()

works fine on this PR.

... interesting wrinkle. If an axes has an_axes_locator that is notNone,tight_layout decides it can't handle it. Here the locator only is supposed to modify things in the direction perpendicular to the onetight_layout needs to worry about, so presumably it should be fine, but the warning still persists and breaks the docs build.

I have to say, this was actually fewer image changes than I was expecting :)
I have a bunch of small nitpicks in there, but overall I think this is a great simplification and really makes the logic easier to understand what is going on than the multi-axes dispatching.

latest commit changes the aspect ratio handling from a data-aspect ratio to a box aspect ratio. The "short" side of the colorbar now always has a linear scale and limits from 0-1, and only the "long" side gets a scale and variable data limits. This simplifies a lot of code..

Note I've added acolorbar.set_aspect andcolorbar.set/get_scale.These will need whats-new entries (done)

Are theset_scale andset_aspect really necessary public functions on Colorbar and not just on the internal axis?

set_aspect: This is generally on anAxes, so why not leave it oncbar.ax and let the new locator work on that?

set_scale: I feel like this could cause confusion. The norm of the colorbar can be out of sync with the scale now? If I call cbar.set_scale('log')`, the ticks would be located in log-space, but the color normalization still done in linear space I believe.

Are theset_scale andset_aspect really necessary public functions on Colorbar and not just on the internal axis?

set_aspect: This is generally on anAxes, so why not leave it oncbar.ax and let the new locator work on that?

This is the same ascolorbar(..., aspect=20), so it really is a colorbar method. The equivalent axes method isset_box_aspect, and indeedset_aspect will not work.

set_scale: I feel like this could cause confusion. The norm of the colorbar can be out of sync with the scale now? If I call cbar.set_scale('log')`, the ticks would be located in log-space, but the color normalization still done in linear space I believe.

I needed to make this method, and didn't see that it needed to be private, but I don't feel strongly about it. Indeed it will only change the scale and not have anything to do with the norm's scale.

Your new AxesLocator is the only thing callingcbar.set_aspect though because you just put it in. I'm suggesting that you can put these two calls up in the locator instead, without introducing new public API. (You added these two calls into ConstrainedLayout already, so I think the same idea could be applied in the Locator)

self.ax.set_box_aspect(aspect)self.ax.set_aspect('auto')

Indeed it will only change the scale and not have anything to do with the norm's scale.

This seems like a real reason not to make this public. In your calls toself.set_scale(), you already have the long axis attribute above, so why not callself._long_axis().set_scale() there instead of introducing the new API?

I'm suggesting that you can put these two calls up in the locator instead, without introducing new public API.

Absolutely. I'm just suggesting it may be more-generally useful as well to be able to set this after creating the colorbar, so why not expose it?

so why not call self._long_axis().set_scale() there instead of introducing the new API?

Yes, there is no reason for it to be public, other than user convenience. As I said, I don't feel super strongly about exposing this, but wehave had requests to change the scale without changing the norm. For instance, it is not completely unreasonable to have a linear scale and a logarithmic norm.

I assume you'll fix the last thing.

@QuLogic, sorry, what "last thing"? The anchor passthrough? I think the new code is correct...

@QuLogic, sorry, what "last thing"? The anchor passthrough? I think the new code is correct...

#20501 (comment)longax wasn't removed.

Thanks@QuLogic and@greglucas for all your help!