treewide: replace custom color scheme generator with Tinty#2289
Conversation
tinty: move from the haskell generator to tinty as a first step tinty: move from the haskell generator to tinty as a first step tinty: move from the haskell generator to tinty as a first step tinty: move from the haskell generator to tinty as a first step
|
now THIS looks nice |
trueNAHO
left a comment
There was a problem hiding this comment.
As a first step, in @trueNAHO 's plan outlined (here), a move away from the Haskell based palette generator is in order.
This PR is exactly what I had in mind for step (1) and the implementation is nearly ready thanks to all the previous countless overhauls in #892.
NAHO recommended flavours but it seems like it's not very maintained + formatting the palette from the command's output requires nasty bash scripting. Hence, @philocalyst recommended tinty and it does do the job!
As such I've replaced the Haskell palette gen with tinty here as the first step.
Considering the simplicity of replacing the palette generator now, I have no strong feelings what tool exactly is being used for now, especially considering that step (2) of the plan would allow end-users to override it.
Unlike in the previously failed Material You to base16 mapping, I have not verified whether Tinty's color extraction is good enough and merely assume it is good. Has anyone tested this PR in a real setup with drastically different background images?
@philocalyst and I will be drafting a data representation and way of handling user's wishes to provide palettes in different schemes, use different generators for different schemes and how to map between schemes if need be so that each theme can be written for a single scheme or multiple if need be.
Does this refer to steps (2) and (3) from the plan?
@make-42, do you want to add @philocalyst as Co-authored-by or Reviewed-by? Before merging this PR, I will dig through the previous #892 discussions to collect all appropriate contribution tags.
| devShells = { | ||
| default = pkgs.mkShell { |
There was a problem hiding this comment.
Similar to in commit 89d5e0b, this single-entry attribute set should be collapsed:
devShells.default = pkgs.mkShell {There was a problem hiding this comment.
This is missing:
diff --git a/flake/packages.nix b/flake/packages.nix
index 4e11148c0..ba768f368 100644
--- a/flake/packages.nix
+++ b/flake/packages.nix
@@ -11,7 +11,6 @@
serve-docs = pkgs.callPackage ../doc/server.nix {
inherit (config.packages) doc;
};
- palette-generator = pkgs.callPackage ../palette-generator { };
};
};
}| nativeBuildInputs = [ | ||
| pkgs.tinty | ||
| pkgs.yq-go | ||
| ]; |
There was a problem hiding this comment.
Nitpick:
| nativeBuildInputs = [ | |
| pkgs.tinty | |
| pkgs.yq-go | |
| ]; | |
| nativeBuildInputs = with pkgs; [ | |
| tinty | |
| yq-go | |
| ]; |
| env = { | ||
| IMAGE = cfg.image; | ||
| POLARITY = cfg.polarity; | ||
| HOME = "/build"; # prevent tinty from trying to write to XDG_HOME/tinted-theming/tinty/config.toml where it doesn't have perms |
There was a problem hiding this comment.
Thanks for suggesting the comment but usually such runtime environment declarations obviously have to do something with permissions or cache:
| HOME = "/build"; # prevent tinty from trying to write to XDG_HOME/tinted-theming/tinty/config.toml where it doesn't have perms | |
| HOME = "/build"; |
| tinty generate-scheme --system base16 --variant "$POLARITY" "$IMAGE" \ | ||
| | yq -o=json \ | ||
| > $out |
There was a problem hiding this comment.
| tinty generate-scheme --system base16 --variant "$POLARITY" "$IMAGE" \ | |
| | yq -o=json \ | |
| > $out | |
| tinty \ | |
| generate-scheme \ | |
| --system base16 \ | |
| --variant "$POLARITY" \ | |
| "$IMAGE" | | |
| yq --output json \ | |
| >"$out" |
| { | ||
| nativeBuildInputs = [ | ||
| pkgs.tinty | ||
| pkgs.yq-go |
There was a problem hiding this comment.
Is there any particular reason to use pkgs.yq-go instead of pkgs.yq?
There was a problem hiding this comment.
I can't answer for them, but I would pick the same. Yq-go seems to be more actively maintained and used (200/2000 commits, similar jump for stars.)
| ]; | ||
| default = "either"; | ||
| default = "dark"; | ||
| description = '' |
There was a problem hiding this comment.
Simplify formatting:
diff --git a/stylix/palette.nix b/stylix/palette.nix
index 044e8f6e..215739a0 100644
--- a/stylix/palette.nix
+++ b/stylix/palette.nix
@@ -17,9 +17,7 @@ in
"dark"
];
default = "dark";
- description = ''
- Whether to apply the dark or light theme.
- '';
+ description = "Whether to apply the dark or light theme.";
};
image = lib.mkOption {| options.stylix = { | ||
| polarity = lib.mkOption { | ||
| type = lib.types.enum [ | ||
| "either" |
There was a problem hiding this comment.
This also requires removing the current "either" normalizations. Find instances by grepping for "either", "dark", and "light".
Related: #2347
| the wallpaper using [Tinty](https://github.com/tinted-theming/tinty). Note that more | ||
| colorful images tend to yield better results. |
There was a problem hiding this comment.
Nitpick:
| the wallpaper using [Tinty](https://github.com/tinted-theming/tinty). Note that more | |
| colorful images tend to yield better results. | |
| the wallpaper using [Tinty](https://github.com/tinted-theming/tinty). Note | |
| that more colorful images tend to yield better results. |
| inputsFrom = [ config.treefmt.build.devShell ]; | ||
| }; | ||
|
|
||
| ghc = pkgs.mkShell { |
There was a problem hiding this comment.
This also requires removing the Haskell linter:
diff --git a/flake/dev/pre-commit.nix b/flake/dev/pre-commit.nix
index 854bc80f..9d804456 100644
--- a/flake/dev/pre-commit.nix
+++ b/flake/dev/pre-commit.nix
@@ -29,7 +29,6 @@
settings.noLambdaPatternNames = true;
};
editorconfig-checker.enable = true;
- hlint.enable = true;
statix.enable = true;
treefmt = {
enable = true;

@philocalyst and I are willing to write the code needed for the switch to a different way of managing palettes.
As a first step, in @trueNAHO 's plan outlined (here), a move away from the Haskell based palette generator is in order.
NAHO recommended flavours but it seems like it's not very maintained + formatting the palette from the command's output requires nasty bash scripting. Hence, @philocalyst recommended tinty and it does do the job!
As such I've replaced the Haskell palette gen with tinty here as the first step.
Waiting for your input on this,
@philocalyst and I will be drafting a data representation and way of handling user's wishes to provide palettes in different schemes, use different generators for different schemes and how to map between schemes if need be so that each theme can be written for a single scheme or multiple if need be.
PS: the polarity "either" option has been removed as it no longer corresponds to a functional mode of the palette generator.