stylix: add darker and even-darker polarities

[make-42]

The default dark polarity is a bit too light and doesn't look good on some LCD displays for that reason.
Therefore darker and even-darker polarities could be a nice addition.

Thank you!

[trueNAHO]

Cc: @danth

---

The default dark polarity is a bit too light and doesn't look good on some LCD displays for that reason. Therefore darker and even-darker polarities could be a nice addition.

Thanks for delving into the code and submitting this patch. However, I am unsure about adding darker and even-darker polarities.

Currently, some Stylix modules use the stylix.polarity option to apply a "light" or "dark" theme variant, while defaulting to "either":

stylix/stylix/palette.nix

Lines 25 to 35 in 4d87b96

	polarity = lib.mkOption {
	type = lib.types.enum [ "either" "light" "dark" ];
	default = "either";
	description = ''
	Use this option to force a light or dark theme.
	By default we will select whichever is ranked better by the genetic
	algorithm. This aims to get good contrast between the foreground and
	background, as well as some variety in the highlight colours.
	'';
	};

Although, this is not how stylix.polarity is supposed to be used:

Currently, dark and light mode are only supported in some Stylix modules.

Really, stylix.polarity is just a setting to guide the palette generator and shouldn't be used in modules at all. It defaults to "either", and even if it's set there is no guarantee that the selected theme actually matches what it says. We should be selecting light/dark mode based on the value of base00 instead.

-- danth, "idea: support a cross browser dark mode extension like dark-reader"

Using stylix.polarity to apply "light" or "dark" themes will probably be deprecated upon completing the following milestone:

• (7) Support automatic polarity switch based on sunset and sunrise 6

-- NAHO, "Roadmap"

However, the proposed darker and even-darker parameters are somewhat arbitrary:

stylix/palette-generator/Stylix/Palette.hs

Lines 96 to 100 in ff7e1e7

	darkerScheme
	= lightnessError (V.fromList [5, 10, 15, 60, 70, 80, 95, 95]) 60
	evenDarkerScheme
	= lightnessError (V.fromList [2, 4, 8, 55, 70, 80, 95, 95]) 60

Instead, we could further generalize stylix.polarity by interfacing all lightnessError parameters through something like stylix.polarity.primaryScale or stylix.polarity.accentValue:

stylix/palette-generator/Stylix/Palette.hs

Lines 68 to 72 in 4d87b96

	lightnessError primaryScale accentValue
	-- The primary scale's lightnesses should match the given pattern.
	= sum (V.zipWith difference primaryScale $ primary lightnesses)
	-- The accent colours should all have the given lightness.
	+ sum (V.map (difference accentValue) $ accent lightnesses)

Considering the current Roadmap, I am unsure how stylix.polarity should be handled in the meantime.

---

Note that completing the following milestone may involve rewriting our in-house palette generator (/palette-generator) or replacing it with some already existing general purpose tool:

• (7) Support automatic polarity switch based on sunset and sunrise 6

-- NAHO, "Roadmap"

[make-42]

Okay! That makes sense! Should I write an stylix.polarity.primaryScale option instead in the meantime or wait for that milestone be reached?

Thank you very much!

[trueNAHO]

Okay! That makes sense! Should I write an stylix.polarity.primaryScale option instead in the meantime or wait for that milestone be reached?

Let's wait on @danth's opinion first.

[make-42]

Sure!

[make-42]

I added options that do that, they go from 0.0 to 1.0 without clipping any colors but if they are pushed beyond that range they clip colors without erroring out as a feature.

[make-42]

[make-42]

This is what setting primaryScale.dark to 0.01 looks like

[make-42]

any updates?

[danth]

Note that completing the following milestone may involve rewriting our in-house palette generator or replacing it with some already existing general purpose tool

I'm all for replacing it with an existing tool, if we can find one.

If not, moving the palette generator to a separate repository and rewriting it in a more well known language would be ideal. There are probably better algorithms we could be using, or definitely more optimized implementations of the current approach (both in terms of generation performance, and the quality of results). Effectively, we build our own general purpose tool, and then have Stylix merely use it rather than the tool being embedded directly into the project.

Considering that it's already possible to override the theme with colors generated from whatever tool you like, I doubt extending the existing palette generator implementation is worthwhile.

[make-42]

I did do just that, I added a few lines to the existing palette generator to get it to work with a scaling factor. Wouldn't that work in the meantime? Using pywal during the build step is also a possibility if we need some preexisting implementation.

[trueNAHO]

Considering that it's already possible to override the theme with colors generated from whatever tool you like, I doubt extending the existing palette generator implementation is worthwhile.

Agreed.

Note that completing the following milestone may involve rewriting our in-house palette generator or replacing it with some already existing general purpose tool

I'm all for replacing it with an existing tool, if we can find one.

If not, moving the palette generator to a separate repository and rewriting it in a more well known language would be ideal. There are probably better algorithms we could be using, or definitely more optimized implementations of the current approach (both in terms of generation performance, and the quality of results). Effectively, we build our own general purpose tool, and then have Stylix merely use it rather than the tool being embedded directly into the project.

Agreed.

Last time I researched this, I found several tools that apparently extract the colors from an image. However, I did not inspect them thoroughly enough to make sure they are actually doing what we need.

I did do just that, I added a few lines to the existing palette generator to get it to work with a scaling factor. Wouldn't that work in the meantime? Using pywal during the build step is also a possibility if we need some preexisting implementation.

Replacing our in-house palette generator in

• (4) Support base24 scheme 7 and Vim highlight groups 5 to resolve styling inconsistencies

NAHO, "Roadmap"

with a general purpose tool and resolving the following task would generally solve this problem:

• (6) Implement slideshow with post-processing capabilities 1 21 22

NAHO, "Roadmap"

Consequently, I am unsure whether we should extend our current palette generator:

Considering that it's already possible to override the theme with colors generated from whatever tool you like, I doubt extending the existing palette generator implementation is worthwhile.

[make-42]

So it would be better to focus on integrating another palette generator instead?

[trueNAHO]

So it would be better to focus on integrating another palette generator instead?

Yes, but it should be compatible with the requirements of the Roadmap. I will look into this once we get to this stage of the Roadmap.

[make-42]

Alright! Thank you very much!