Built-in theme toggler
Have you checked for existing feature requests?
- [X] Completed
Summary
In Settings/Themes, provide two sets of themes, while making the active one toggleable by keybinding.
What benefits does this feature provide?
Faster to switch between Dark/Light themes throughout the day, following work environment. It could also be used for other purpose than Dark/Light.
Any alternatives?
I currently use an unmaintained old atom package, namely "theme-toggler 0.7.0". A bit laggy and also triggers deprecation cop. Theme selection is harder to find and duplicated inside the package settings.
Other examples:
Any application with a Dark mode
Check this package: https://web.pulsar-edit.dev/packages/auto-dark-mode
This isn't a bad idea at all, and we did somewhat touch on this topic over in #545 (emphasis on somewhat).
But I'd personally be for providing this functionality, especially if we ever wanted to be able to respond to changes in the OS theme.
The Electron app I work on for my day job handles this in (arguably) the right way: a setting controls whether the app uses light mode, dark mode, or the system default. (The third option allows it to adjust from one to the other automatically if the OS itself switches at a certain time of day.)
Of course, it's more complicated than that for Pulsar, since the UI and syntax themes are explicitly divided into light and dark. I had a thought a while back to build a syntax theme that could do both in one, but I ended up having to do a lot of duplication because of how much we rely on Less variables (instead of CSS variables) and never followed through.
But I've also got it in my head that we should gradually nudge our theme systems toward CSS variables in general, so maybe this is also worth revisiting.
New core setting
Suppose someone wanted to write an “omni” theme — one that could flip between light mode and dark mode. If they used the standard system (media query with prefers-color-scheme:) I think it would follow the OS's setting for color scheme. The only thing missing would be the ability to override the default color scheme of the OS. (I can imagine it would be a popular setting to force dark mode for Pulsar even when the rest of the OS is using a light scheme.)
So let's envision a new Core setting:
- Color scheme: Whether to force light mode or dark mode or use the OS’s setting. Values: light, mode, system default.
We can respond to changes in this setting by changing the value of nativeTheme.themeSource. I believe this API is present in Electron 12. This controls how prefers-color-scheme: media queries behave throughout the renderer process by telling the CSS which kind of theme the user prefers.
CAVEAT: We've got a behavior that tries to work the opposite way: it analyzes whether the current UI theme is light or dark and tries to set nativeTheme.themeSource in a way that harmonizes with it. This is probably a mutually exclusive behavior from what I'm proposing above, so maybe we can add it as a fourth option.
Explicit switching between two themes
Once this is done, I think the rest gets easier. I personally don't think it needs to be a core package, but maybe others disagree. A package like auto-dark-mode will work even better if we make prefers-color-scheme: more useful; and if someone wants to make it a core part of the theme manager, it wouldn't add a whole lot of code.
I don't have the energy for this, but maybe some enthusiastic contributor will come by who cares about it: all of our syntax and UI themes can be combined into half as many by unifying the -light and -dark versions. The emergence of explicit light/dark support in CSS makes this much easier.