Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
jklymak merged 1 commit intomatplotlib:mainfromoscargus:colorbarlocation
Nov 7, 2022

Conversation

oscargus
Copy link
Member

@oscargusoscargus commentedJun 14, 2022
edited
Loading

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:
image
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

  • Has pytest style unit tests (andpytest passes).
  • IsFlake 8 compliant (installflake8-docstrings and runflake8 --docstring-convention=all).

Documentation

  • New features are documented, with examples if plot related.
  • New features have an entry indoc/users/next_whats_new/ (follow instructions in README.rst there).
  • [N/A] API changes documented indoc/api/next_api_changes/ (follow instructions in README.rst there).
  • Documentation is sphinx and numpydoc compliant (the docs shouldbuild without error).

@oscargus
Copy link
MemberAuthor

I also realized that there is a change here that may not really be wanted (or it may be). Earlier, passing e.g.orientation='horizontal' always gave ticklocation'bottom'. Now, if passingorientation='horizontal' and a validlocation, the ticklocation depends on if the location is'top' or'bottom'. Which makes sense and is consistent with what location does formake_axis andmake_axis_gridspec.

timhoffm reacted with thumbs up emoji

@oscargusoscargusforce-pushed thecolorbarlocation branch 2 times, most recently frombdb43a3 tof44b0b4CompareJune 18, 2022 09:01
@oscargusoscargus marked this pull request as ready for reviewJune 18, 2022 09:05
@story645
Copy link
Member

story645 commentedJun 19, 2022
edited
Loading

This is awesome and I'm fairly sure should get a new feature/what's new write up.

Copy link
Member

@jklymakjklymak left a 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.


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
Copy link
Member

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

Copy link
MemberAuthor

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 bycolorbar (passed to eithermake_axes ormake_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).

Copy link
Member

@timhoffmtimhoffm left a 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?

@oscargus
Copy link
MemberAuthor

oscargus commentedJun 22, 2022
edited
Loading

_normalize_location_orientation also setsanchor,panchor andpad. I wasn't sure that one wanted those to be modified here? Also, here we need to keep the original value oflocation to keep track of iflocation andorientation was passed.

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...).

@oscargus
Copy link
MemberAuthor

I'll think it through more carefully, but the rationale at the time was this.

@timhoffm
Copy link
Member

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_normalize_location_orientation to avoid duplication - if that helps.

@oscargusoscargus marked this pull request as draftJuly 7, 2022 07:18
@oscargus
Copy link
MemberAuthor

Got around to this and at least now it is checked and set in a single location.

@oscargusoscargusforce-pushed thecolorbarlocation branch 2 times, most recently from08c2062 to0442dd3CompareAugust 18, 2022 19:52
@oscargusoscargus added this to thev3.6.0 milestoneAug 18, 2022
@oscargusoscargus marked this pull request as ready for reviewAugust 18, 2022 19:56
@tacaswelltacaswell modified the milestones:v3.6.0,v3.7.0Aug 19, 2022
@oscargusoscargusforce-pushed thecolorbarlocation branch 3 times, most recently from0515d39 toee796c5CompareNovember 2, 2022 13:31
@oscargus
Copy link
MemberAuthor

Finally got back to this. The unrelated test is dropped.

Copy link
Member

@jklymakjklymak left a 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


ticklocation : {'auto', 'left', 'right', 'top', 'bottom'}

drawedges : bool

filled : bool

location : None or {'left', 'right', 'top', 'bottom'}
Copy link
Member

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?

Copy link
MemberAuthor

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.

@jklymakjklymak merged commitf975291 intomatplotlib:mainNov 7, 2022
@jklymak
Copy link
Member

Thanks@oscargus - definitely useful addition!

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@story645story645story645 left review comments

@timhoffmtimhoffmtimhoffm left review comments

@anntzeranntzeranntzer approved these changes

@jklymakjklymakjklymak approved these changes

Assignees
No one assigned
Projects
None yet
Milestone
v3.7.0
Development

Successfully merging this pull request may close these issues.

[ENH]: Colorbar should support location kwarg that sets both orientation and ticklocation
7 participants
@oscargus@story645@timhoffm@jklymak@anntzer@tacaswell@QuLogic

[8]ページ先頭

©2009-2025 Movatter.jp