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

Don't mark a patch transform as set if the parent transform is not set.#9426

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
tacaswell merged 2 commits intomatplotlib:masterfromanntzer:shadow-transform
Jul 8, 2018

Conversation

anntzer
Copy link
Contributor

When updating a patch from another artist, if the other artist's
transform is marked as "uninitialized" (_transformSet == False), then
don't mark the updatee's transform as set either.

Typically, this occurs if the updator has not been added to an Axes yet;
its transform will be set when that adding occurs. In that case, the
updatee's transform also needs to be set when actually being added to an
Axes.

Closes the incorrect transform part of#9377.

PR Summary

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@jklymak
Copy link
Member

Is there a good test for this?

dstansby
dstansby previously requested changesOct 19, 2017
Copy link
Member

@dstansbydstansby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Just putting a reminder here to include an image test related to#9435

@tacaswelltacaswell modified the milestones:v2.2,v2.1.1Oct 19, 2017
@tacaswell
Copy link
Member

Sorry, changed my mind about where to target this to again.

@anntzer
Copy link
ContributorAuthor

anntzer commentedOct 21, 2017
edited
Loading

To be honest, looking at it again, I am not even that certain that that the constructor of that Shadow class makes a lot of sense. Specifically, if I got it correctly, the ox and oy values are first multiplied by the dots-per-point conversion factor (e.g. 100/72 at 100dpi), then interpreted as offsets indata coordinates.

Which "of course(???...)" means that the shadow can move when you save the figure (as savefig.dpi does not have to equal figure.dpi)

@tacaswell
Copy link
Member

Looking at the history this goes back to JDH in 2004 so it pre-dates the transform machinery and I would guess added as a gee-whiz feature.

If you think it could be cleaned up for 2.2 👍

@anntzer
Copy link
ContributorAuthor

anntzer commentedOct 21, 2017
edited
Loading

I'm not really convinced of the utility of providing this class, but heh.

A problem with interpreting ox, oy as offsets in data units is that the only two public APIs that rely on that class (other than Shadow itself) arepie(..., shadow=True) andlegend(..., shadow=True), and for pie charts (which set the axes to polar) you'd betternot interpret ox, oy in data coordinates.

So perhaps ox, oy should be interpreted either as axes coordinates or figure coordinates -- don't have a clear preference right now.

Edit: I think I'll let@dstansby figure out how to handle the same problem with arrows and just copy his approach :-)

@anntzeranntzer modified the milestones:needs sorting,v3.0Feb 15, 2018
@anntzeranntzerforce-pushed theshadow-transform branch 2 times, most recently fromf99506f to71ec6c3CompareFebruary 17, 2018 00:41
@anntzer
Copy link
ContributorAuthor

@dstansby test has been added (a while ago, but no worries)

@efiring
Copy link
Member

@dstansby Would you like to re-review and merge if it is OK?

@anntzeranntzer mentioned this pull requestJun 10, 2018
6 tasks
When updating a patch from another artist, if the other artist'stransform is marked as "uninitialized" (`_transformSet == False`), thendon't mark the updatee's transform as set either.Typically, this occurs if the updator has not been added to an Axes yet;its transform will be set when that adding occurs.  In that case, theupdatee's transform also needs to be set when actually being added to anAxes.
@anntzeranntzer added the Release criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. labelJul 7, 2018
@anntzer
Copy link
ContributorAuthor

Seems ready to go in for 3.0 so labeling as RC.

@tacaswelltacaswell merged commit3d19f94 intomatplotlib:masterJul 8, 2018
@anntzeranntzer deleted the shadow-transform branchJuly 8, 2018 22:02
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@efiringefiringefiring approved these changes

@dstansbydstansbydstansby left review comments

Assignees
No one assigned
Labels
Release criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Milestone
v3.0.0
Development

Successfully merging this pull request may close these issues.

5 participants
@anntzer@jklymak@tacaswell@efiring@dstansby

[8]ページ先頭

©2009-2025 Movatter.jp