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]

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.