Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Fix colorbar aspect when colorbar created, not its axes...#22100
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This logic also fails, because we modify the box_aspect as part of the algorithm to shrink the axes for extend triangles. So if we redraw, we keep making the colorbar aspect smaller and smaller! |
I think theproper solution here is that colorbar needs to know its aspect ratio, and that the user cannot control the underlying axes aspect ratio directly. I think that can mostly work now, but we would need to grow a |
PR Summary
Closes#22087 (?)
Creating a colorbar axes and then subsequently setting its aspect ratio after creation, but before creating the colorbar, failed after#20501. That is because the new colorbar logic consults
cax._colorbar_info
for the aspect ratio of the colorbar, and we were setting that when the colorbar axes was created. Here we change the logic so the aspect ratio is not set until the colorbar is put into the axes.#22087 is still broken in that users used to be able to set the aspect ratio via
cax.set_aspect
, whereas now we are usingcax.set_box_aspect
. That could maybe be fixed.We probably should also allow a way for colorbars to reset their aspect ratio (#20588).
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).