feat: dark and light theme support #442
Conversation
| darkFlavor = lib.mkOption { | ||
| type = catppuccinLib.types.flavor; | ||
| default = config.catppuccin.flavor; | ||
| description = "Global Catppuccin dark flavor"; | ||
| }; | ||
|
|
||
| lightFlavor = lib.mkOption { | ||
| type = catppuccinLib.types.flavor; | ||
| default = config.catppuccin.flavor; | ||
| description = "Global Catppuccin light flavor"; | ||
| }; |
There was a problem hiding this comment.
I'm not too big a fan of this API. I think it'd be better to have a single enum option defining whether or not to use dark mode, and continuing using the local flavor option in modules (which should be fine since both can still be overridden on a per-module basis if you'd like light mode with a different-than-global flavor for example)
i.e., this would become
{
# Or maybe name it `mode`? I dunno
theme = lib.mkOption {
type = lib.types.oneOf [ "light" "dark" ];
default = dark;
description = "Global Catppuccin theme type";
example = lib.literalExpression "light";
};
}There was a problem hiding this comment.
I see the idea, but i assume some people like macOS users would be more wanting to have the dark and light options since they are not enforced into declarative light/dark.
There was a problem hiding this comment.
Oh and totally forgot for ghostty which is a single string, making it a bit hard to do that.
There was a problem hiding this comment.
I'm not too sure how else to generalize this API then. Having dynamic light/dark is virtually exclusive to macOS, and most apps will just not support it; I don't know where else this would really be used besides Ghostty and Zed
If we can configure either of those two to use a "dynamic" mode, I would be fine with that being a third option in this enum -- and those two ports having their own exclusive light/darkFlavor options. Otherwise I don't think this is a good fit here
| @@ -19,11 +24,11 @@ in | |||
| userSettings.theme = { | |||
| light = | |||
| "Catppuccin " | |||
| + catppuccinLib.mkUpper cfg.flavor | |||
| + catppuccinLib.mkUpper cfg.lightFlavor | |||
There was a problem hiding this comment.
This would stay the same
| + catppuccinLib.mkUpper cfg.lightFlavor | |
| + catppuccinLib.mkUpper cfg.flavor |
| + lib.optionalString (!cfg.italics) " - No Italics"; | ||
| dark = | ||
| "Catppuccin " | ||
| + catppuccinLib.mkUpper cfg.flavor | ||
| + catppuccinLib.mkUpper cfg.darkFlavor |
There was a problem hiding this comment.
And then we would configure zed to use the light or dark theme
...assuming that's possible. I'd really like it to be since I feel like making the light/dark theme choice imperative is a bit odd and unlike what we do with flavors, accents, and enabling the themes themselves
Perhaps a oversight but a understandable one seeing as we currently only have 1 reactive theme, zed. But that may change with the addition of ghostty!
closes #420
The idea here was to introduce
darkFlavorandlightFlavorin a very none breaking way, such that they both default toconfig.catppuccin.flavorrather thenmochaandlatterespectively.