Dark mode for custom color schemes

[jackfirth]

I like to use the drracket-solarized color scheme, which comes in light and dark flavors. DrRacket's GUI switches from light to dark when I use dark mode on my mac, but it doesn't change the color scheme from solarized light to solarized dark. Would it be possible to support that?

[rfindler]

This would be great. Currently a dark theme and is corresponding light theme aren't linked. But if that information were made available via the theme then DrRacket could totally switch between them (at startup) based on the underlying OS's white-on-black or black-on-white setting (well, except on windows where we don't seem to know how to get that information).

I've also seen bad color choices because someone chose a nice scheme in dark mode and then switches to light mode and it looks really bad because DrRacket takes its cue from the underlying OS setting for some colors and the theme for other colors and they might be right next to each other in some cases.

[jackfirth]

What would be a good way for themes to specify this information?

[rfindler]

Right now a theme is specified as basically a color mapping (from some set of names that the docs tell you how to get) via an info.rkt file. Probably there is a reasonable place in there to add in (backwards compatibly) some kind of a reference to another theme. Or maybe when themes come together as a bow/wob pair we could have a new name in the info.rkt file that had both of them at once.

What do you think?

[jackfirth]

Looking at the definition for the solarized themes, it looks like a list of hashes where each hash is a theme. Maybe we could represent the combination of a light and dark theme as a different kind of hash that doesn't have the colors key and instead has a key with a list of the two themes?

#lang info

(define framework:color-schemes
  `(#hash((name . "Solarized Light")
          (colors . ...))
    #hash((name . "Solarized Dark")
          (white-on-black-base? . #t)
          (colors . ...))
    #hash((name . "Solarized")
          (light-and-dark-subthemes . ("Solarized Light" "Solarized Dark")))))

[rfindler]

What about adding a key into the existing hash that names the matching opposite-color scheme? That seems like it would require fewer changes to existing themes (and to the code that deals with them)?

Just in case, the docs are here.

[AlexKnauth]

Or, what if the "Preferences -> Colors -> Color Schemes" page allowed an option for "use as light-mode color scheme" and "use as dark-mode color scheme".

This might be more flexible if, say I like the Solarized Light scheme for light-mode, but for dark-mode I prefer Tol's white-on-black over Solarized Dark.

The downside is there is no automatically-provided association between Solarized-Light and Solarized-Dark, so it requires slightly more work for the user setting the preferences.

[rfindler]

The motivating example for me is when someone chooses a color scheme that looks good only in one mode and switches to the other mode and we end up with really hard to read colors. That suggestion wouldn't help with that person. Also, the suggestion of linking things wouldn't make life worse than the status quo for someone that prefers unlinked color schemes as they currently have to go click to change.

That said, there may be a design that would accommodate both that would work.