8000 consult rcParams for Figures on `fig.clf` · Issue #7434 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

consult rcParams for Figures on fig.clf #7434

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kaufman opened this issue Nov 9, 2016 · 11 comments
Closed

consult rcParams for Figures on fig.clf #7434

kaufman opened this issue Nov 9, 2016 · 11 comments
Labels
API: consistency New feature status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. status: inactive Marked by the “Stale” Github Action

Comments

@kaufman
Copy link
Contributor
kaufman commented Nov 9, 2016

version: 2.0.0b1+1773.g3590ce2
installed from src, OSX, gtk backend

if I have in rcParams:
figure.subplot.top=0.9

and I do:

figure()
clf()
plot([],[])
draw()
show()

then, the top margin is respected, but if I already have a window with figure already open and I do

style.use('x') # where x.mplstyle has figure.subplot: 0.5
clf()
plot([],[])
draw()

then then top margin is not altered from 0.9 (like I might expect when changing the style).
I have to close the window and create a new one for this style change to have an effect. This is not expected behavior.

@tacaswell
Copy link
Member

Yes, the rcparams are locked in when the objects are created, thus changing the rcparams / style only affects newly created objects.

This is a feature so that style context managers work.

@kaufman
Copy link
Contributor Author
kaufman commented Nov 9, 2016
edited
Loading

Then it seems that clf() is not performing quite as much work as I thought. Would it be possible to modify subplots_adjust() to take no arguments and simply update to the current set of rcParams? That way, changing the margins inside a context manager would work as long as you add the subplots_adjust() function call (and if the rcParams margins are the same as the figure margins it would act as a noop).

@tacaswell tacaswell added this to the 2.1 (next point release) milestone Nov 9, 2016
@tacaswell tacaswell added New feature API: consistency new-contributor-friendly Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues labels Nov 9, 2016
@tacaswell
Copy link
Member

So the current behavior of subplots_adjust (which it gets from the update method of SubplotParams is to update only the values that are being changed by the call, and fall back to the rc values if they have never been set. I would wager some users are calling fig.subplots_adjust(**some_dict) which this request would change the behavior of in the case of an empty dictionary.

It might be reasonable to reset the subplots params to the rcvalues in clf, but then we should do that for all of the rcparams that figure pulls in.

We should add a flag to clf to disable the rcparam fetching. If we default the flag to True this is a minor API break (the figure will be in a slightly different state after clf that it used to be), but not one I am super worried about.

Milestoned as 2.1 as this would be (in my view) a new feature, but if it gets done it would not be hard to convince me it should be back ported to 2.0.

The exact work here is:

  • sort out which rcParams are consulted while creating a Figure object
  • add a flag to clf (and it's aliases) to optionally re-consult those values

I think most of the effort will be tracking down all of the rcParams used.

@tacaswell tacaswell changed the title changing subplot margins with style.use() requires window close() for effect consult rcParams for Figures on fig.clf Nov 9, 2016
@kaufman
Copy link
Contributor Author
kaufman commented Nov 9, 2016

I like this plan.

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Sep 24, 2017
@tacaswell tacaswell added the Good first issue Open a pull request against these issues if there are no active ones! label Oct 16, 2017
NNiehof added a commit to NNiehof/matplotlib that referenced this issue Oct 29, 2017
Optionally fetch rcParams again in clf, issue matplotlib#7434
@NNiehof
Copy link
NNiehof commented Oct 29, 2017

Hello, I'm interested in contributing to matplotlib, and this seemed like a good way to start! I've made the requested changes (see #9622). I'd like to ask for a few hints if that's alright. When I try to recompile matplotlib with my changes, the newly installed version doesn't seem to have my changes. I'm working in a conda environment (in Windows 7), from which I've removed matplotlib. Then installed it again with conda install --use-local matplotlib, which successfully installs it, but apparently without the changes I've made. Do you have any advice on how to properly recompile and test, for each new change? I would much appreciate it.

@jklymak
Copy link
Member
jklymak commented Oct 30, 2017

Hi @NNiehof. I use pip as described in the developer guide in the docs. You’ll also find very helpful instructions for how to use git and style guides etc. Good luck!

@NNiehof
Copy link
NNiehof commented Oct 31, 2017

@jklymak Thanks, I'll give that another go. I spent most of my Saturday getting matplotlib to install from source, the pip method didn't work then, because the dependencies and virtual environment weren't set up properly yet. Maybe now that's sorted out, building with pip as in the docs will work.

@afvincent
Copy link
Contributor
afvincent commented Oct 31, 2017

@NNiehof Just in case you don't already know that it exists: if you are struggling on a technical point, the Matplotlib gitter channel is (sometimes) more reactive that the issue tracker. Hopefully you won't need it ;).

@NNiehof
Copy link
NNiehof commented Oct 31, 2017 via email

@tacaswell tacaswell removed Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues Good first issue Open a pull request against these issues if there are no active ones! labels Dec 4, 2022
@tacaswell
Copy link
Member

There is a slightly bigger discussion going on over what clear should mean, I have removed both the easy and good first issues labels as while the technical work is straight forward, there are some conceptual issues that need to be sorted.

Copy link
github-actions bot commented Dec 6, 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!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Dec 6, 2023
@github-actions github-actions bot added the status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. label Jan 6, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 6, 2024
5C7A Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API: consistency New feature status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. status: inactive Marked by the “Stale” Github Action
Projects
None yet
6 participants
0