-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Could element_geom
use aesthetic argument names?
#6347
Comments
There is a need to differentiate functions. In the same vein, there is a difference in line functions in that isolated lines have |
Still a bit confused, but assume you guys know what you're doing |
@teunbrand Only noticed this now, and wanted to point out that while I agree in principle with your argument for foreground colors and background colors I think it's important to distinguish between things that take up small areas (points, lines) versus large areas (filled areas) in the foreground. You cannot normally apply the same color to a line that you would to a filled area and vice versa. The filled area needs to be much lighter/less saturated. So this may require two different types of foreground colors, one that corresponds to typical This would also alleviate the issue with the boxplot in my opinion, as to me the filled box is foreground, but with an appropriate color for foreground fill, not foreground line drawings. A simple way to convert a foreground line color into a foreground fill color is usually to just add some transparency, so that could be the default option when you set the ink value for lines/points. |
I think I understand now the reason for this naming is to provide flexibility when applying aesthetics to all geoms. An idea is to create an extra function |
Let's reopen this to air some additional space for discussion.
I'd broadly agree with this notion, but the way this is currently implemented is as mixtures between foreground and background. For example
I'd agree with this when |
Thanks for reopening. Are you interested in the idea of providing an
In addition to this:
I feel that to have both options would provide the best of both worlds: flexibility of |
I'm interested in discussing what good solutions are. The current solution is just one that works and fits with preserving previous defaults, but I'm always interested in improving on that. With regards to your specific proposal about |
When we merge #6285, we'll be able to do this: devtools::load_all("~/packages/ggplot2/")
#> ℹ Loading ggplot2
ggplot(mpg, aes(drv, displ)) +
geom_boxplot() +
theme_light() +
theme(
geom.boxplot = element_geom(paper = "grey95")
) Created on 2025-02-27 with reprex v2.1.1 It is not directly basing the fill from |
Ah, Ok, so yes this achieves everything I wanted. I guess the main confusion is going to be over whether it's the Now that I think about it, Either way, I think having colors getting mixed in the geom is not a good idea. I like color mixing as a good default, but in designing a theme I would definitely want to override it and do my own manual mixing. |
Ok so if we're talking about the specifications we want out of the new theme-based defaults, we'd like:
Feel free to correct me or include additional specifications if you want. There are two possible paths I can see to adhering to these specifications.
Happy to hear alternatives if these spring to mind |
I would probably have a small preference for the first option, as I agree with @davidhodge931 that reasoning about With Option 1, wouldn't you also set the default fill in the theme to |
Yes, but instead of having a single element, you'd have to populate a whole bunch of them. This also has as consequence that Geom extensions, which we cannot populate from e.g. |
@teunbrand Clearly you have thought this through more carefully than I have. So I'll defer to your judgement. Again, the only thing that I'd like to ask is that I can override any default color mixing in the theme. |
I appreciate the input Claus! I'll also discuss with Thomas about his views before moving on with finishing #6285. |
element_geom
looks like a cool new feature.Was wondering if there is a reason why colour/fill etc are not used - and instead ink/paper etc are?
It'd be cool if the arguments could align with the aesthetic names.
So currently like this...
This would seem much more intuitive...
Sorry if I'm missing something
The text was updated successfully, but these errors were encountered: