Skip to content

Navigation Menu

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

Appearance settings

Add rcParams for Axes(3D) parameters #25642

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
Loading
from

Conversation

oscargus
Copy link
Member

@oscargus oscargus commented Apr 7, 2023

PR Summary

Add separate rcParams for Axes and Axes3D for aspect, anchor, and adjustable. Also proj_type for Axes3D.

Closes #8088

PR Checklist

Documentation and Tests

  • Has pytest style unit tests (and pytest passes)
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • New plotting related features are documented with examples.

Release Notes

  • New features are marked with a .. versionadded:: directive in the docstring and documented in doc/users/next_whats_new/
  • API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/
  • Release notes conform with instructions in next_whats_new/README.rst or next_api_changes/README.rst

@oscargus oscargus force-pushed the axesrcparams branch 2 times, most recently from b03a5d7 to 4d73b6c Compare April 7, 2023 10:27
@oscargus oscargus changed the title Add rcParams for Axes creation Add rcParams for Axes(3D) parameters Apr 7, 2023
@oscargus oscargus added this to the v3.8.0 milestone Apr 7, 2023
Comment on lines +434 to +437
#axes3d.adjustable: box # {box, adjustable}
#axes3d.anchor: C # {C, E, N, S, W, NE, NW, SE, SW} or two-tuple of floats
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not inherit these from axes.adjustable or axes.anchor? A lot of other 3D properties fall back on this without setting an explicit 3D param.

Copy link
Member Author

Choose a reason for hiding this comment

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

#25641 :-)

One can for sure discuss which can be the same and which are beneficial to have separately.

Copy link
Contributor

Choose a reason for hiding this comment

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

#25641 is definitely interesting.

For this one, as defaults, maybe defaulting to what is done is 2d is useful?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, I do not get it. Are you saying that if the 3D-version of the RCparam is not changed, but the 2D-version is, it should use the 2D-version? How do we know if the style-sheet has set the 3D-version to the default value or not? I may be missing something, but I didn't think it was possible to query if the param comes from the style sheet or if the default is used?

Also, wouldn't that be a bit confusing? Now we add double parameters that are also physically located quite nearby, so I guess if someone want to change the 2D-case, chances are that they will notice the 3D-case as well?

Then it may very well be that it is not worthwhile to have separate 2D and 3D versions for all parameters introduced here. aspect and ´adjustableseems to make sense to have separately, which leavesanchor`. That was basically just added because it ended up nearby in the code and I realized that it could be done.

Copy link
Contributor

Choose a reason for hiding this comment

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

So, I found a few places where we do this

self._axinfo.update({
'axisline': {
'linewidth': mpl.rcParams['axes.linewidth'],
'color': mpl.rcParams['axes.edgecolor'],
},

wherein a 3d parameter is set on based on the value of a "2d rcparam", which is why I thought we can use mpl.rcParams['axes.anchor'] directly.

Now, I personally would prefer more rcParams instead of less with inheritance as you mentioned, but I brought it up because there were some such examples. Am not opposed to adding the new rcParams though.

Copy link
Member Author

Choose a reason for hiding this comment

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

OK, then I understand. Yes, it is not a problem as such, more a question of which parameters we would like to separate.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes. But I guess that's a part of a bigger conversation about the role of rcparams itself. For now, I don't mind having all 3 separate parameters either.

@oscargus
Copy link
Member Author

oscargus commented Apr 25, 2023

Converting to draft as I added box_aspect as well and there are two things to figure out.

  1. For Axes, the argument can take on None or a float. However, it is not obvious how to know if the user passed None as the default value or if the user wanted to override a non-None rcParam.
  2. For 3DAxes there is also a zoom-parameter to set_box_aspect. Does it make sense to add that as well? I think so. axes3d.box_aspect_zoom?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

rcParams for plt.axis('equal') not working?
5 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.