-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Add location keyword argument to Colorbar #23267
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
Conversation
d976ac0
to
f2cd4da
Compare
I also realized that there is a change here that may not really be wanted (or it may be). Earlier, passing e.g. |
bdb43a3
to
f44b0b4
Compare
This is awesome and I'm fairly sure should get a new feature/what's new write up. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with the need for a what's-new.
f44b0b4
to
8695000
Compare
|
||
The ``colorbar`` method now supports a ``location`` keyword argument | ||
to more easily position the color bar. This is useful when providing | ||
your own inset axes using the ``cax`` keyword argument and behaves |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this sounds like this kwarg only works with a passed in cax & if that's not the case than please also add an example for the not-cax case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The earlier version is documented, but is not used by colorbar
(passed to either make_axes
or make_axes_gridspec
. I agree, however, that the current formulation is not ideal. Will try to modify it (now that I reminded myself of the differences).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've not yet followed the details here, but I would have expected that this can build on top of _normalize_location_orientation
. Am I wrong there?
So while it could be used, it couldn't just be used to update the kwargs and it would do some additional stuff as well, which seemed redundant to me (but now there is redundant code instead...). |
I'll think it through more carefully, but the rationale at the time was this. |
You could also introduce a lower-level function that is used here and inside of |
8695000
to
e0b1df1
Compare
Got around to this and at least now it is checked and set in a single location. |
08c2062
to
0442dd3
Compare
0515d39
to
ee796c5
Compare
Finally got back to this. The unrelated test is dropped. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a small documentation concern
lib/matplotlib/colorbar.py
Outdated
|
||
ticklocation : {'auto', 'left', 'right', 'top', 'bottom'} | ||
|
||
drawedges : bool | ||
|
||
filled : bool | ||
|
||
location : None or {'left', 'right', 'top', 'bottom'} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs some description about how it interacts with orientation and ticklocation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a bit of text (copied from the top) and updated the docs for ticklocation. There should maybe be another way to describe how all these are related if only some are given.
ee796c5
to
e87cd5e
Compare
e87cd5e
to
8b4ad6c
Compare
Thanks @oscargus - definitely useful addition! |
PR Summary
Closes #22676
Is this an API change or a user change?
Will add an unrelated test for #23260 here as well.Added. However, they do not look great... The png looks OK, but locally I get in Spyder:so there it seems like there is a bit of overlap that is not visible in the test image. For the svg there is a gap instead, although this seems to depend on the renderer...
Also, I do not understand why the test images are not just four squares as the pasted image...PR Checklist
Tests and Styling
pytest
passes).flake8-docstrings
and runflake8 --docstring-convention=all
).Documentation
doc/users/next_whats_new/
(follow instructions in README.rst there).doc/api/next_api_changes/
(follow instructions in README.rst there).