Inner colorbar & Outer colorbar

[leejjoon]

Create colorbar at the inner- of outer- side of axes. Unlike the original colorbar command, the location of the original axes is not changed.

import numpy as np
import matplotlib.pyplot as plt

arr = np.arange(100).reshape((10,10))
ax = plt.subplot(111)
im = ax.imshow(arr)

from mpl_toolkits.axes_grid1.colorbar import inner_colorbar
cb = inner_colorbar(ax, im, loc=2)

plt.show()

See examples/axes_grid/demo_colorbar.py.

[efiring]

Requiring a numeric code is rather unfriendly and harms readability of user code. It would be nice to have location specifications and codes factored out, and encourage use of names. Even in mpl code, names would be better where possible. One concise naming method for such location is map-oriented: e.g. NE is upper right, CE is center right, C is center, etc. Or one could use T for top, B for bottom, L for left, R for right, and C for center.

[WeatherGod]

My vote would be to be consistent with how legends are done (but without "best"). So, map names would be best.

[mdboom]

I agree with the other comments here. If those were addressed, I think this would be a worthwhile addition.

Also, this should have a regression test.

[pelson]

I can't help but see one word with this variable name, I think the variable name ypadding would probably make things clearer (I would personally go for y_padding, but that is probably a bit inconsistent with other variable names in matplotlib).

[pelson]

I find it a real shame to see that such a fantastic feature wont be available in the mainstream mpl colorbar. I don't know the history, but was it, and is it still, entirely necessary to take a fork of the standard colorbar classes? Essentially, what we are seeing is a divergence of functionality (for instance, one class can do inner colorbars, the other can do hatched colorbars - as a user, just pray you don't want both), and an added complexity to the end user about how to produce a colorbar in matplotlib (if you want to do x and y you want this kind of colorbar, but if you want to do z you need this kind of colorbar).

Is there any way we can reconcile and factor in the necessary changes from mpl_toolkits.axes_grid1.colorbar back into matplotlib.colorbar?

[pelson]

Again, I have readability issues with this. xborderpad is better, x_border_pad is best (but most inconsistent with the rest of the code).

[pelson]

Is there any way we can reconcile and factor in the necessary changes from mpl_toolkits.axes_grid1.colorbar back into matplotlib.colorbar?

@leejjoon : I'm guessing the answer to this is no. If that is the case, then, once @WeatherGod is happy his comments are addressed, I don't see any value in holding this PR up (there is already some awesome functionality in axes_grid which is not available to a "native" user [such as me] which I would hope, in the future, we can port back into the core of mpl).

@leejjoon : Are you in a position to move this forwards?

Thanks,

[leejjoon]

The proposed functionality uses Colorbar class from the matplotlib. But it depends on axes_grid1's functionality to place the colorbar "axes" relative to the parent axes. So, unless axes_grid1 becomes the mainstream part of matplotlib, it is not possible to put this into matplotlib.colorbar.py.

In fact, I now think that the current approach is not as good as I originally thought. I have some idea on an alternative (better) approach but not sure when I can start working on. I am not sure what is best option to do with this PR for now. Maybe we put some label on it and close?

[pelson]

Maybe we put some label on it and close?

I've added the "onging" label, and will close. Thanks @leejjoon