I'm not convinced by the motivation here. When do we want to pass afigure to a plotting method while at the same time wanting the user to be able to control layout parameters? It seems the only reason to pass a figure to a method is if we want to control the layout in our method. Can you justify this a little more?

Overall the newset_layout seemsvery long, and I'm not convinced we want to encourageset_layout after the figure is instantiated. In particular, colorbars need to know what layout is being used before they are created (for historical reasons, but they would be hard to remove at this point).

I think the motivation here is reasonable. We already moved to a singlelayout kwarg (preferred overtight_layout andconstrained_layout). Coupled with#20426 , I think providing a way for users to after-the-fact change the layout engine is an obvious feature (think of the case of using xarray / pandas to make most of a figure and then tweaking it up).

@stanleyjs You have taken on an ambitious project for your first PR, anything extending (let alone changing) the API tends to result in very verbose discussions (because a lot of our day-to-day pain in related to APIs that in in 20/20 hind sight were not the best). Please bear with us while we work through the process.

Yes but my point is that currently youcannot tweak it up after the fact if you have used a colorbar so an explicit setter will fail

Hi just wanted to bump this and see what the timeline is moving forward.

A few things.

1. The primary motivation and concern of this PR was to increase uniformity in the API between the figure constructor and its actual setters/getters. In the current codebase, downstream figure instantiation / manipulation has to be done through special cases, as, for example, settingfigsize post instantiation must be translated toset_size_inches. This is confusing.
2. I'll admit thatset_layout is a little bit long. It had four requirements:
   a) Accomodate all of the current API, which includes both modernlayout and legacytight_layout +constrained_layout.
   b) Abstract the current instantiation code into its own method
   c) Allow for subsequent modification of the layout parameters
   d) Raise the correct set of warnings for undefined behavior.
   As a result, the method suffers a bit and could be easily refined by removing support for the legacy attributes.
3. At least in my applications, which may not be matplotlib parlance, I find myself often settingconstrained ortight_layout before and after making colorbars and legends
4. Ifset_layout is holding this PR up, I think we should at least push through the other new aliases.
5. Is it worth looking into how to make colorbars in a way that works independent of the order that the layout is set? I can look into this for a separate PR.

I will look into this from the API consistency point of view. But I'll take some time because I don't have much time for matplotlib currently. There are always tradeoffs between API improvements, compatibility with the existing API and redundant ways to do the same thing. Usually, you cannot have all.

5. Is it worth looking into how to make colorbars in a way that works independent of the order that the layout is set? I can look into this for a separate PR.

I have looked into this extensively, and its certainlypossible, but not in a back-compatible way.

Conversely you could use the current design, pull the colorbar out, hoist the parent axes to their original gridspec, and redo the layout (or vice versa), but that seems really brittle and not worth the bother.

I'm not convinced there is a great use case to toggle the two layout managers that would justify adding all the extra cruft needed to make this work, particularly given how poorlytight_layout works with colorbars in the first place. In my (very biased) opinion if you have colorbars you should be using constrained_layout because it was specifically designed to work around the issues with colorbars in tight_layout.

There have been substantive changes tofigure.py that cover these layout methods. I'm still not convinced this re-arrangement is a substantial improvement, but others may have a different opinion. It has acquired the need for a rebase. I'll leave active for others to comment on. I think we were waiting for@timhoffm to weigh in.

@jklymak while I still believe that it doesn't make any sense for certain constructor arguments to not have a correspondingset_arg method, I think that is a separate thing from attempting to restructure the layout interface/construction. For that reason, I'm open to closing this, but I think a new, smaller PR would be reasonable to at least aliasset_figsize toset_figsize_inches

a new, smaller PR would be reasonable to at least aliasset_figsize toset_figsize_inches.

We currently have

• Figure(figsize=...)
• Figure.get_figwidth()
• Figure.get_figheight()

So, yes I agree that we should haveset_figsize() andget_figsize().@stanleyjs sorry for the delay in reviewing. Are you willing to open a PR for that?

@timhoffm yes. Sorry for the delay. I will try to get this on the list for this weekend.
Jay

@stanleyjs are you still interested in opening a PR?

Thank you for your work on this@stanleyjs ! I created#24617 writing up the more limited version of this PR and am going to close this. Working code is a good articulation of requirements, but I opted to open a new issue in favor of closing this PR to make it more likely for someone else to pick up this work.

hmm