Geom aesthetics based on theme

[teunbrand]

This PR aims to partially fix #2239 and is intended to replace #2749.
It is a work in progress as a few things might need to happen before this is viable (more at the end about this).

The main gist is that there is a from_theme() function that works in a similar fashion to after_stat()/after_scale()/stage().
During Geom$use_defaults(), this will be used for masked evaluation from a new theme element.
See example below for a quick demo:

devtools::load_all("~/packages/ggplot2")
#> ℹ Loading ggplot2

p <- ggplot(mpg, aes(displ, hwy)) +
  theme(geom = element_geom(ink = "purple"))

p + geom_point(aes(colour = from_theme(ink)))

It also works from the geom defaults, but this isn't implemented in any geom yet, as a few geoms (notably geom_sf()) are recalcitrant to this method.

update_geom_defaults("point", aes(colour = from_theme(ink)))

p + geom_point()

^{Created on 2024-04-08 with reprex v2.1.0}

There are a few topics for discussion that mostly mirror those in #2749.

• Current colour options in element_geom() are ink, paper and accent. You can think of ink and paper as foreground and background respectively and could be renamed fg and bg if that is deemed more intuitive.
• The main reason I didn't went with colour_1, colour_2, fill_1, fill_2 etc as discussed in Allow default geom aesthetics to be set from theme #2749, is because from_theme() could allow you to mix colours on the spot and you wouldn't need a large number of colours to account for all the different grayscale defaults in the geoms. See also next point.
• I would like a colour mixing function so that we could hypothetically do the following for e.g. GeomRect:

  default_aes = list(
    ...,
    fill = from_theme(col_mix(ink, paper, amount = 0.35))
  )
  

  This probably has a more comfortable home in the {scales} package, as I think we'd need {farver} for this and ggplot2 only indirectly depends on {farver}.
• geom_sf() performs typical Geom tasks (like setting defaults) in the sf_grob() and would require a bit of refactoring to wire this geom up directly.

[teunbrand]

Update: added text parameters to element_geom(), which are set when using complete themes.
base_family and base_size populate these parameters.

devtools::load_all("~/packages/ggplot2/")
#> ℹ Loading ggplot2

ggplot(mtcars, aes(wt, mpg, label = rownames(mtcars))) +
  geom_text() +
  theme_gray(base_family = "Montserrat", base_size = 22)

^{Created on 2024-04-17 with reprex v2.1.0}

[teunbrand]

This is in a useable state now, with almost all geoms completing colour/fill/linewidth/family/(font)size defaults from the theme.
Because from_theme() can have expressions, we can generate the whole grayscale gradient by mixing the paper (white) and ink (black) settings.

What isn't done up to this point:

• geom_sf(), it would need Refactor applying defaults in geom_sf() #5834 for it to work.
• There is a shim for colour mixing, which we can remove when Additional colour manipulation functions r-lib/scales#424 is accepted.
• There is a failing test I'm hesitant to change because I'm unsure about what the complete attribute exactly entails in a <theme> object. For example I don't know why we would expect a complete theme in the line below:

ggplot2/tests/testthat/test-theme.R

Line 224 in 9243e2f

expect_true(attr(p$plot$theme, "complete"))

Aside from these points, I'd be happy for any feedback on the direction, so I'm un-WIP-ping this PR.

[teunbrand]

Small update:

• geom_sf() now has themeable defaults.
• Failling test was removed. Assumption earlier was that theme wasn't built/completed after ggplot_build(), and now it is.

devtools::load_all("~/packages/ggplot2")
#> ℹ Loading ggplot2

nc <- sf::st_read(system.file("shape/nc.shp", package = "sf"), quiet = TRUE)

ggplot(nc) +
  geom_sf() +
  theme(
    geom = element_geom(ink = "forestgreen")
  )

^{Created on 2024-04-29 with reprex v2.1.0}

[teunbrand]

So I've tried to figure out why the revdep failures exist and here is a short description of failures that occurred more than twice in order of frequency. Here is my digestion of the issues:

• Failures via {plotly} (60 times)
  • Partially due to this PR but also due to New spacing and margins root theme elements #5631 in that some theme elements are not calculated that should be. I think this is best fixed by sending a PR to {plotly} fixing these issues. EDIT: Compatibility with incoming ggplot2 changes plotly/plotly.R#2368
• Missing plot labels (38 times)
  • Not related to this PR, but relates to Default labels from attributes (option 2) #5879.
• Failures {patchwork} (35 times)
  • Not related to this PR, patch already merged (Use calc_element() instead of theme subsetting thomasp85/patchwork#365)
• Failures via {ggdist} (19 times)
  • Related to this PR, due to {ggdist} implementing a custom use_defaults() that doesn't have theme in the signature. This is probably best solved by sending a PR to {ggdist}. EDIT: use_defaults() method passes extra arguments mjskay/ggdist#241
• Failures via {ggnewscale} (16 times)
  • Not related to this PR, but relates to Default labels from attributes (option 2) #5879. Probably best solved by sending a PR. EDIT: ggnewscale 0.5.0, which was just released on CRAN appears to not have any of these issues 🎉
• Unknown reasons (15 times)
  • The 'I don't know: I give up' category of failures. These packages failed for reasons beyond my skillset to diagnose or will take a thorough deep dive to diagnose.
• Accessing default values (8 times)
  • Packages using something like GeomPoint$default_aes$colour for whatever reason. These packages probably need a PR to wrap access to these default values.
• Using width = NULL as parameter to layer() (5 times)
  • Not related to this PR, but relates to Set width as aesthetic in geom_col()/geom_bar(). #5807. Because width is now an aesthetic, it is incompatible with 0-length specifications, whereas this wasn't the case as parameter.
• False positives (4 times)
  • Failures due to installed package size sitting on the 5Mb threshold and such. They shouldn't be related to this PR or even ggplot2.
• Failures via {ggforce} (4 times)
  • Not related to this PR but to Refactor facet panel drawing code #5917
• Failures due to length(ggplot()) or names(ggplot()) (4 times)
  • Not related to this PR, discussed in Regressions related to #5879 #6008.
• Tests require updates (3 times)
  • Related to this PR, tests that require simple updates because "grey35" is now sometimes "#595959" and whatnot.
• Miscellaneous reasons (28 times)
  • 22 other reasons that are (almost) unique

[teunbrand]

The current status of this PR is as follows;
I've tried to remove most friction between this PR and reverse dependencies.
This included small tweaks to this PR, but also new PRs to e.g. {ggdist} and {plotly}.
There are some inevitable changes that dependencies would have to make.

Some reverse dependencies will need to update some of their code to deal with default aesthetics that no longer are constants.
To make this somewhat easier, I've made a get_geom_defaults() helper that resolves from_theme() aesthetics.
I can still send out PRs to these packages if necessary. The packages are {ggpol}, {inTextSummaryTable}, {xaringanthemer}, {entropart}, {geomtextpath}, {ggdark}, {gghighlight}.

I don't think there is any more work to be done on this PR at the moment and I'd recommend merging this after review so that unforeseen issues can be reported.

[thomasp85]

Did we land on a decision on thin+thick, vs stroke+line (or something to that accord)?

Also, we should add linetype for completeness.

I'm approving so you are not blocked going forward, but let's clear the above questions before merging

[thomasp85]

Can you remind me again why we can NULLify these?

[teunbrand]

Eventually pch = outlier.shape %||% data$shape where data$shape has been filled from GeomBoxplot$default_aes. Not setting these to NULL would then block the theme-inherited aesthetics from reaching the points. The logic is the same for outlier.size.

[teunbrand]

Did we land on a decision on thin+thick, vs stroke+line (or something to that accord)?

I don't think we did, but I don't have strong feelings either way. What seems more appropriate to you?

Also, we should add linetype for completeness.

Will do!

[EvaMaeRey]

Did we land on a decision on thin+thick, vs stroke+line (or something to that accord)?

'outline' or 'border' instead of 'stroke' is probably more consistent with everyday terminology.