Add vistool_theme to ggplot2

[manuelhelmerichs]

Hopefully fixes #30 - could you take a look?

[jemus42]

Why does vistool_theme() return an object of class vistool_theme rather than "just" a ggplot2 theme?

Is there a benefit to starting from scratch like this and defined a different class rather than starting from a ggplot2::theme()?
See for example how other packages define ggplot2 themes:

• https://github.com/jrnold/ggthemes/blob/d87e5deebc6ac4902da1a1a25aa00ed081a32567/R/fivethirtyeight.R#L10-L37
• https://github.com/hrbrmstr/hrbrthemes/blob/d3fd02949fc201c6db616ccaffbb9858aec6fd2b/R/theme-ipsum.r#L72-L171

My suggestion would be to define a theme_vistool() (canonically the naming schemes is theme_xyz() for ggplot2 themes) which uses ggplot2's themeing functions alone, unless you have a different plan?

For other plotting systems like plotly we'd need a bespoke solution I guess, but a one-size-fits-all solution would be hard, if at all possible.

[manuelhelmerichs]

Currently, vistool_theme supports both the plotly and the ggplot2 backend (thus it was just a plain list, which every visualizer uses to set its options) and wasn't meant to be just (or at all really) a ggplot2 theme, but a way to customize a visualizer or multiple plots at once (see https://slds-lmu.github.io/vistool/articles/customization_guide.html, would be happy about feedback, the docs are clearly not polished yet). I believe it does make sense to be able to apply this theme to other ggplot2 plots. The reason for this implementation is that ggplot2 routes + additions through the generic ggplot_add() and this in turn looks for a method based on the class of the object we're adding (so for vistool_theme, ggplot_add.vistool_theme()). Does this make sense?

[jemus42]

Ah yes, checks out.

From the perspective of "we want a default ggplot2 theme for plots on lecture slides, even for non-vistool plots" I'd still prefer to have a "normal" ggplot2 theme exported from the package, so people can just do ggplot(...) + theme_vistool() or theme_set(vistool::theme_vistool) for their plots without having to be aware of "non-standard" theme stuff 🧐

Supporting ggplot2 and plotly at the same time might be a bit counter-intuitive, I'd recommended two distinct theme functions, one for ggplot2 and one for plotly, which under the hood of course might rely on the same values, so there's no duplication / copy paste hell hopefully, does that make sense?

[jemus42]

What's the status here?

I see theme_vistool() is now function cool!
I initially planned to add this myself but if you want to continue with this it's fine by me.
Other things I had planned were:

• Use viridis (or related) color themes as defaults via the theme, which is possible since ggplot2 4.0.0 (see also Scale palettes from theme tidyverse/ggplot2#5946) (a unified (accessible) color theme is the main goal from my perspective here)
• Add ... to theme_vistool() so ad-hoc adaptations can be made on the fly without having to add another + theme(...) line (I do this all the time for stuff like legend.positon = ... and other things where a " one true global default" is hard)

[manuelhelmerichs]

Sorry for the late reply - both are implemented now. Please take another look :)

[jemus42]

Sorry for the late reply as well 🥴

I see the automatic palette setting works now, cool!
Unfortunately for the discrete case I think we need a better default, currently for two categories I can barely tell apart the colors as opposed to when I manually tweak the viridis settings:

library(vistool)
library(ggplot2)

getOption("vistool.theme")
#> $palette
#> [1] "viridis"
#> 
#> $text_size
#> [1] 11
[...]


p <- ggplot(mtcars, aes(x = wt, y = mpg, color = factor(vs))) +
  geom_point() +
  theme_vistool()
p

p +
  theme(
    palette.colour.discrete = scales::pal_viridis(
      option = "H",
      begin = 0.2,
      end = 0.8
    )
  )

^{Created on 2026-01-27 with reprex v2.1.1}

Not sure what to do here ideally, maybe it's worth switching scales for the discrete case, such as RColorBrewer's Dark2 palette:

Which I believe has a good "reputation" in terms of accessibility.

The scico palettes could also be useful, primarily in case we need diverging scales (with a neutral mid-ppoint, e.g. 0, and then clearly distinguishable low- and high-ends). That's kind of a special case though.

[manuelhelmerichs]

Yes, improved defaults are definitely needed, not only for the colour scheme but also for text sizes, line widths, etc. I will merge this PR now and open a new issue (and ~immediately start working on that) for those - I believe that is a separate concern, also across both plotly and the ggplot2 backends.