Repository navigation
axes_grid in main library #17095
Description
As pointed out by @anntzer
OTOH it may be nice to slowly move axes_grid towards an API more consistent with the rest of mpl. From a very, very quick look, I guess its
axisdict could be compared to normal axes'spinesdict? (an AxisArtist is vaguely like a Spine, I guess).
Originally posted by @anntzer in #17069 (comment)
I think it would be better if we had a new axes_grid functionality in the main library, giving us freedom to change the API as we see fit.
The issue that axes_grid fixes is fundamentally:
import matplotlib.pylot as plt
fig, axs = plt.subplots(2, 3 figsize=(5, 3))
for ax in axs.flat:
ax.set_aspect(1)returns the following:
whereas axes_grid would pack these together vertically.
from mpl_toolkits.axes_grid1 import AxesGrid
fig = plt.figure(figsize=(3, 4), facecolor='0.7')
axs = AxesGrid(fig, 111, # similar to subplot(111)
nrows_ncols=(2, 3),
)
for ax in axs:
ax.set_aspect(1)
(Asside, yes, AxesGrid also makes some sharing assumptions, etc, that need not be made in general)
Neither constrained_layout nor tight_layout will do this packing for us.
proposals?
There are a few possible top-level APIs for this. The simplest may be:
axs = fig.add_axes_grid(gs)
where gs is a subplotspec, just like add_subplot.
Activity
anntzer commentedon Apr 23, 2020
I had a look at whether tight-packing could easily be achieved with tight_layout, but having spent a bit of time on it, I think the problem is underconstrained if you don't have assume some amount of sharing or at least that all axes have a fixed box_aspect (or fixed aspect + adjustable="datalim", which amounts to the same). Indeed, assume you have the following layout
where 1a and 1b are "square" axes and Xa and Xb have no aspect contraints, and assume additionally that the figure is initially too tall, so there's plenty of space between 1a and 1b:
Now do we add a lot of margins at the top and bottom to bringing 1a and 1b close to one another, at the cost of also squishing Xa and Xb which were just minding their own business and were able to use all the height available to them?
Obviously we "can" make a choice of behavior here, but then do we want to make that configurable, yada yada.
jklymak commentedon Apr 23, 2020
I'd argue that layout is squished as is. You squish vertically if the tallest element in each row still have vertical space
Would also be as good as you can get.
I am working on all this logic for
_constrained_layoutbut I'm not convinced its any different fortight_layoutFor what I've done so far, the real issues come in when there are colorbars....
jklymak commentedon Apr 23, 2020
@anntzer its a complete mess right now, but this is what I did for CL so far: #17232
github-actions commentedon Jul 21, 2023
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!
jklymak commentedon Jul 21, 2023
This is basically
layout='compressed'so I think we can close this.