treewide: replace custom color scheme generator with Matugen
This PR is meant to further the discussion in (https://github.com/danth/stylix/pull/694).
I believe matugen could be a good candidate for replacing the builtin color scheme generation engine stylix currently uses and this PR serves as a demo for it.
The code is not final:
- the old engine is still in the codebase
- polarity doesn't work like it's supposed to (it selects the color scheme and "either" defaults to black)
- a lightnessScale parameter could also be implemented as in: https://github.com/danth/stylix/pull/694
- the choice of colors used in the dark and light themes might need to be changed.
However this is what it looks like:
Closes: https://github.com/nix-community/stylix/issues/269 Closes: https://github.com/nix-community/stylix/issues/1862
primaryScale parameters have been implemented
primaryScale.dark = -0.05; gives you:
and primaryScale.dark = -0.1; gives you:
Okay, I'll work on cleaning this up, do I remove the code for the old palette-generator or do I make an option to have it be selectable for legacy purposes?
I fixed all of the issues that you brought up.
Do you want me to create a gallery of different color scheme options?
although for some reason, i can't get the removed option warning to show up
that was an easy fix...
very cool! will this be able to extend to generating a base24 or vim highlight group scheme?
The base16 palette colors are exposed through config.lib.stylix.colors.baseXX, same as before, so you could definitely make any custom color scheme you want for vim if you don't like the default mappings.
As for base24 support that'd just involve exposing an extra 8 colors (matugen generates more colors than we use so that is definitely possible) and could probably be done if the project owners were okay with doing so. Although that would then force people to add the extra 8 colors if they want to import their own color palette and as of now no theme would take advantage of the extra colors.
As for base24 support that'd just involve exposing an extra 8 colors (matugen generates more colors than we use so that is definitely possible)
awesome! that's good futureproofing and tackling #252
do I remove the code for the old palette-generator or do I make an option to have it be selectable for legacy purposes?
The current palette generator was designed essentially through trial and error, so I'm not surprised that matugen is a lot better at generating nice looking themes. I would just remove it.
(Some more history - the original idea for Stylix was to take just a single option, that being the wallpaper, and do everything automatically from there. This is why the palette generator exists, and why #200 was an issue for so long.)
Anyone who wants to continue using a color scheme from the old palette generator may read /etc/stylix/palette.json or $XDG_CONFIG_HOME/stylix/palette.json before updating, and copy the values into their configuration as a manually defined scheme.
I'm also not sure about the colors I have assigned to the Base16 colors based off what matugen returns. I went with what looked good to me but they might need reassigning...
(also that last commit seems to have broken some things...)
CI is failing. Maybe a git rebase master resolves the issue: https://github.com/danth/stylix/commit/65c42633d4d0ebc49e8f077c289786b13a145509.
Let's see
error: 'checks.aarch64-linux' is not an attribute set... I'll look into it right now.
Might be easier to create a new branch and apply my changes from there instead of rebasing... Will do that instead...
still fails...
maybe it's because the palette-generator module is removed?
Why should I put instead? stylix.themeGeneration.polarity is supposed to exist. I'll set it back to stylix.polarity to see if it works...
Oh but stylix is redefined just before so that's normal I suppose.
okay all tests pass except deadnix telling me that i need to remove the pkgs argument in flake.nix at lines 212, 226 and 239 but when i do all the other tests fail since they seem to rely on it...
okay all tests pass except deadnix telling me that i need to remove the
pkgsargument in flake.nix at lines 212, 226 and 239 but when i do all the other tests fail since they seem to rely on it...
I think you are supposed to replace the
Warning: Unused declarations were found.
╭─[flake.nix:212:11]
212 │ { pkgs, ... }@args:
│ ╰── Unused lambda pattern: pkgs
227 │ { pkgs, ... }@args:
│ ╰── Unused lambda pattern: pkgs
241 │ { pkgs, ... }@args:
│ ╰── Unused lambda pattern: pkgs
instances with just:
args:
Still the same error...
i have no idea how to fix the warning
The error message is pretty strange since the attribute set that is said to not exist in the tests does seem to exist:
[nix-shell:~/Downloads/stylix]$ nix-tree --derivation '.#checks.aarch64-linux'
error: expected flake output attribute 'checks.aarch64-linux' to be a derivation or path but found a set: { docs = «thunk»; git-hooks = «thunk»; nix-flake-check = «thunk»; palette-generator = «thunk»; "testbed:alacritty:default:dark:image:scheme:cursor" = «thunk»; "testbed:alacritty:default:dark:image:scheme:cursorless" = «thunk»; "testbed:alacritty:default:dark:image:schemeless:cursorless" = «thunk»; "testbed:alacritty:default:dark:imageless:scheme:cursorless" = «thunk»; "testbed:alacritty:default:light:image:scheme:cursorless" = «thunk»; "testbed:cavalier:default:dark:image:scheme:cursor" = «thunk»; «119 attributes elided» }
nix-tree: Received ExitFailure 1 when running
Raw command: nix path-info --json --derivation --extra-experimental-features "nix-command flakes" .#checks.aarch64-linux
I had to force deadnix to not flag these specific lines. There might be a better solution but I can't find it.
hmm, that's really weird. are you using the pre-commit?
(from my testing on your branch, it doesn't seem like it'd change anything, but i'm still interested to know)
Based on https://github.com/astro/deadnix/commit/a8c3e265c52dffe50e63e7f4b5068f27cc78f8b5, it seems that # deadnix: skip is the only reasonable workaround.
@make-42, what is the status of this PR?
If not for the weird deadnix warning, and unless you object, or want to add extra (base24) colors this PR should be ready.