Will probably take some time to fully review, but I very much like the idea. Do you want to get the proplot author involved as well?

@lukelbd would this have obviated some of the special classes in proplot? Instead of a special class, you could just have had a layout engine that adjusted your figure to have a larger size in proportion to the fixed-width subplots. (Of course other features of proplot would still be implemented separately)

Very cool — this is definitely a big improvement. However I don’t think proplot can use it unfortunately.

Proplot’s GridSpec subclass also makes the major backwards-incompatible change of specifying spacing parameters in physical units rather than figure-relative units and subplot-relative units (with em-widths as the default and other units accepted as strings through the physical units engine). For example, right=1 sets the right margin to 1 em width.

It also permits variable spacing between rows and columns (which addresses some use cases for GridSpecFromSubplotSpec), implements a “panel” system for subplot panels and colorbars (where some grid spec slots are hidden and constrained to have fixed widths), and forces users to use a single GridSpec per figure (if they are working manually with GridSpecs).

Maybe some of those later points could be implemented with a layout engine but overall the changes and restrictions are probably too drastic for that to work.

Although I could be wrong. Don't think I fully understand the scope of this feature.

Thanks@lukelbd - the goal here is to give downstream libraries and users a draw-time hook that is specifically to be used to change layout. That draw time hook can do what you want with it, though it definitely does not hang extra meta info off gridspecs or axes.

Out of scope for this PR, but if you have suggestions for easy, back compatible, extra meta info that would be useful to add to gridspec and/or axes (min margin sizes etc) that input would be welcome. You could certainly imagine variable minimum column separator widths in gridspec that then are respected by whatever the layout manager is.

I'm between option A (no change) and B (only change if we know it is safe). I am inclined to go with A for now as it is API safe to relax that restriction in the future (so we are not painting our selves into a corner) and is is simpler (and we are signing up to support something of unknown (but probably high) complexity). To some degree we can think of this as a way to get atFigureTightLayout andFigureConstrainedLayout via composition rather than inheritance.

Even if we never relax this, users can work around it by adding one more layer of indirection. ALayoutEnigneDispatcher that exposes some knob to switch between compatible layout engines should be possible to make in an API compatible way ("All problems in computer science can be solved by adding a layer of inderection. All performance problems can be solved by removing a layer of indirection" 😈 ).

The direction I am more concerned that it is possible to share an engine instance across figures (which it looks like you can do now asget_figure is never exercised (I put in suggestions to remove all of the code around that)).

Newest commits:

1. implement C above. The check is if any axes have a_colorbar attribute, which gets added by acolorbar call.
2. make colorbar_gridspec and adjust_compatible properties of the classes (ahem, I think I did it correctly)

jklymak#2 has some additional commits for this (including a fix to the failing test).

@jklymak I merged what I think fixes a stray.dpi , I plan to merge this is CI is green.

🎉 I'm excited to get this in!

Thanks for all your help@anntzer,@QuLogic,@timhoffm and@tacaswell I know this was a big one to get in.