Inheritance of theme-based aesthetics

[teunbrand]

This PR is an amendment to #5833.

Briefly, we want to deprecate update_geom_defaults() and to do that we need to increase the flexibility of the theme based styling of geom defaults. In this PR, we include inheritance of theme-based aesthetics to allow finer customisation.

In order to make this not too restrictive, we're allowing any theme(geom.* = element_geom()), which takes same logic in terms of theme validation.

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

class(GeomDensity)
#> [1] "GeomDensity" "GeomArea"    "GeomRibbon"  "Geom"        "ggproto"    
#> [6] "gg"

ggplot(mpg, aes(displ)) +
  geom_density() +
  theme(
    geom.ribbon = element_geom(borderwidth = 2),
    geom.area = element_geom(bordertype = 2),
    geom.density = element_geom(ink = "red")
  )

^{Created on 2025-01-21 with reprex v2.1.1}

[thomasp85]

@clauswilke and @yutannihilation I'd like your eyes on this and especially our bid to fully make update_geom_defaults() disposable.

I always really disliked that global state change that update_geom_defaults() incur but can also see why people have used it - I think the above change strikes a nice middle ground but as someone who never uses update_geom_defaults() I might have blind spots

[teunbrand]

Just to give away one weakness of the approach; people can change specifically the colours of geom_point() using this mechanism, but not the fill because GeomPoint$default_aes gives fill = NA instead of fill = from_theme(...)).

[clauswilke]

@teunbrand Don't issues such as the fill one you point out just mean that geom defaults would have to be updated accordingly?

In principle, I think this is 100% the right direction to go. I also dislike update_geom_defaults(). It will require a lot of adjustments from extension package authors though, I would assume. And I know many people update geom defaults globally. I see it all the time in bug reports and other issues.

[yutannihilation]

I agree this is 100% the right direction!

One thing I'm still unsure is how long it takes until the "ink" mechanism gets understood by the majority of ggplot2 users and the extension developers. I personally feel the trickiness @teunbrand pointed out is understandable, but we might hit more cases like that, especially on Geoms provided by the extension package. It's not visible to users which aesthetic of a Geom supports from_theme() unless they read the source code, right? Regarding this point, an ordinary user might feel update_geom_defaults() is simpler.

[teunbrand]

Thanks for taking a look Claus and Hiroaki!

Don't issues such as the fill one you point out just mean that geom defaults would have to be updated accordingly?

Yes they can be, it just would make me slightly grumpy that there then would be 3 places where defaults are defined, which is hard to track/explain. (i. the default_aes field, ii. the geom theme setting and iii. geom.point theme setting). The thing I like about the current solution is that there is only (i) and (ii) and the user is in complete control of (iii).

One thing I'm still unsure is how long it takes until the "ink" mechanism gets understood by the majority of ggplot2 users and the extension developers.

Thomas and I have discussed putting together a deep-dive blogpost on how to theme/style your plots, so this is definitely something that I planned to include in such post.

It's not visible to users which aesthetic of a Geom supports from_theme() unless they read the source code, right?

You can also print e.g. geom_point()$geom$default_aes. Alternatively, we could do something along the lines of #5461 to make this more clear.

[yutannihilation]

Thanks, I'm looking forward to the blog post! #5461 looks a good solution if it's possible.