-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Rename size aesthetic for line-based geoms #3672
Conversation
Team - I would like to get this into the next release as it will be primarily focused on cleaning up code, syntax, and internal, and I feel the current behaviour is a major logical issue... Are there any objections to this change in API? |
Will this require all extension packages to make changes to their code? I like the idea conceptually, but I think we need to think carefully about how the transition will work. If downstream packages need to change their code, can they easily support the new and the old ggplot2 at the same time? |
That is a good question to bring up... This will not break any extension packages (I think), but it will also not magically transform them into understanding So there will be an API consistency issue between ggplot2 and the extension packages in terms of aesthetic naming until they are updated. However, I think our dev community has generally reacted quite fast on these types of updates |
Conflicts: R/geom-abline.r R/geom-hex.r R/geom-map.r R/geom-polygon.r R/geom-ribbon.r R/geom-segment.r R/legend-draw.r
The implementation of this has now been improved significantly from the point-of-view of updating geoms and ensuring a smooth transition. In order to upgrade a geom implementation to use What you get for free when setting |
I will go through adding unit tests for all the affected geoms etc, but before that, I'd like some input about the current approach @hadley @clauswilke @yutannihilation |
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.
LGTM!
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.
Looks great in general, though I'm not yet sure what this change will mean to the extension packages. Minor comments.
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.
Thanks for adding a note. Looks good!
Conflicts: tests/testthat/_snaps/draw-key/time-series-and-polygon-key-glyphs.svg
Just curious, will this eventually change the behavior of For example, in the case of geom_pointrange(size = 10) |
At this point the ambiguous geoms will not differentiate but I think we would do that down the line after proper deprecation |
I see. Sounds good to me. Let's file an issue for it when we merge this. |
This is a draft PR that seeks to rename the
size
aesthetic whenever it refers to the width of a stroke. There are two problems with the current setup:It conflates two distinct aesthetics making it difficult to control each one separately when working with geoms that contain both points and lines/polygons, e.g. boxplot, linerange, and sf.
As the default size scale is area based, scaling of stroke width is not linear by default, and it is needed to use
scale_radius()
to change that which is super counterintuitiveFor the most part we can change this without backward compatibility issues as
size
can be renamed tolinewidth
if present insetup_data()
. A few geoms have need for both as discussed in 1.) and we can not do any inference there meaning that there might be visual breakage in these cases. The pros outweigh the cons considerably though (IMO).The aesthetic name
linewidth
has been chosen as bothwidth
andstroke
is already in use.linewidth
also falls in line with thelinetype
aesthetic.Please use this PR for discussions