palette: If `stylix.base16Scheme` is set, don't generate palette, or provide option to disable generation

[sylvorg]

Description

Hello!

Would it be possible to disable palette generation if stylix.base16Scheme is set, or just an option to disable it entirely? I would just like to use stylix.image for setting the wallpaper, if possible, as I'm using agenix and sops-nix with a "secret" wallpaper, so the wallpaper isn't available until around after the configuration is activated.

Alternatively, perhaps a stylix.wallpaper option could be implemented, which stylix.image and stylix.targets.kde would use if stylix.base16Scheme is not set.

Thank you kindly for your consideration on the matter!

Submission Checklist

• I assert that this issue is relevant to Stylix
• I assert that this is not a duplicate of an existing issue

Notify maintainers

No response

[trueNAHO]

Would it be possible to disable palette generation if stylix.base16Scheme is set, or just an option to disable it entirely?

Ideally, this should be the case, but as evident by commit 58b1de7 ("stylix: refactor base16Scheme and lib.stylix.colors assertion (#1446)") this has been enforced to ensure correctness because this was a common source of bugs.

Although this should be possible to implement, this would require refactoring non-trivial sections of the code base, which is why this has not been done yet.

One workaround would be to use #1956 and make the palette generator a no-op, although this is rather inconvenient.

I would just like to use stylix.image for setting the wallpaper

Resolving this is already part of the roadmap:

• (3) Optionalize top-level options

-- #534

I'm using agenix and sops-nix with a "secret" wallpaper, so the wallpaper isn't available until around after the configuration is activated.

This sounds like a very niche use case that might be resolved once stylix.image points to a run time directory:

• (6) Implement slideshow with post-processing capabilities
  [...]
  • treewide: implement image editor #477 (comment)
  • treewide: implement image editor #477 (comment)

-- #477 (comment)

See #2119 for additional context.

Alternatively, perhaps a stylix.wallpaper option could be implemented, which stylix.image and stylix.targets.kde would use if stylix.base16Scheme is not set.

I am not exactly sure what you mean, but since commit 953c3fb ("stylix/mk-target: generate options for configuring safeguarded arguments") it is possible to disable certain module parts on a target-level.

[sylvorg]

For your last point, perhaps everywhere stylix uses stylix.image to set the wallpaper, it can use a new stylix.wallpaper option instead, something like the following:

{ config, lib, ... }: {
  stylix = {
    wallpaper = /path/to/wallpaper;
    image = lib.mkIf (config.stylix.base16Scheme == null) config.stylix.wallpaper;
  };
  dconf.settings = {
    "org/gnome/desktop/background" = {
      color-shading-type = config.stylix.imageScalingMode;
      "picture-uri${lib.optionalString (config.stylix.polarity == "dark") "-dark"}" = config.stylix.wallpaper;
    };
  };
}

[trueNAHO]

For your last point, perhaps everywhere stylix uses stylix.image to set the wallpaper, it can use a new stylix.wallpaper option instead, something like the following:

{ config, lib, ... }: {
  stylix = {
    wallpaper = /path/to/wallpaper;
    image = lib.mkIf (config.stylix.base16Scheme == null) config.stylix.wallpaper;
  };
  dconf.settings = {
    "org/gnome/desktop/background" = {
      color-shading-type = config.stylix.imageScalingMode;
      "picture-uri${lib.optionalString (config.stylix.polarity == "dark") "-dark"}" = config.stylix.wallpaper;
    };
  };
}

Unsure whether

stylix.image' =
  lib.mkIf (config.stylix.base16Scheme == null) config.stylix.image;

would generally even make sense.

Whether arguments from our module system are considered enabled, is checked in the following function:

stylix/stylix/mk-target.nix

Lines 195 to 200 in a4406d9

	areArgumentsEnabled = lib.flip lib.pipe [
	lib.attrsToList
	(builtins.all (
	{ name, value }: value.enable or (value != null) && cfg.${name}.enable or true
	))
	];

I think fixing this really requires refactoring the core code around the palette generator, stylix.base16Scheme, and stylix.image.

That being said, if it was unclear from

Alternatively, perhaps a stylix.wallpaper option could be implemented, which stylix.image and stylix.targets.kde would use if stylix.base16Scheme is not set.

I am not exactly sure what you mean, but since commit 953c3fb ("stylix/mk-target: generate options for configuring safeguarded arguments") it is possible to disable certain module parts on a target-level.

you can can disable one of the

• stylix/modules/gnome/hm.nix

  Lines 16 to 22 in a4406d9

  	{ cfg, image }:
  	{
  	dconf.settings."org/gnome/desktop/background" = {
  	picture-uri = lib.mkIf cfg.useWallpaper "file://${image}";
  	picture-uri-dark = lib.mkIf cfg.useWallpaper "file://${image}";
  	};
  	}

• stylix/modules/gnome/hm.nix

  Lines 68 to 131 in a4406d9

  	{ inputs, colors }:
  	let
  	extension = pkgs.gnomeExtensions.user-themes;
  	activator = pkgs.writeShellApplication {
  	name = "stylix-activate-gnome";
  	text = ''
  	get_exe() {
  	for directory in /run/current-system/sw/bin /usr/bin /bin; do
  	if [[ -f "$directory/$1" ]]; then
  	printf '%s\n' "$directory/$1"
  	return 0
  	fi
  	done
  	echo "Skipping '$1': command not found"
  	return 1
  	}
  	if gnome_extensions="$(get_exe gnome-extensions)"; then
  	extension=${lib.escapeShellArg extension.passthru.extensionUuid}
  	case "$1" in
  	reload)
  	"$gnome_extensions" disable "$extension"
  	"$gnome_extensions" enable "$extension"
  	;;
  	enable)
  	"$gnome_extensions" enable "$extension"
  	;;
  	esac
  	fi
  	'';
  	};
  	in
  	{
  	home.packages = [ extension ];
  	dconf.settings = {
  	"org/gnome/shell/extensions/user-theme".name = "Stylix";
  	"org/gnome/desktop/background".color-shading-type = "solid";
  	};
  	xdg = {
  	dataFile."themes/Stylix/gnome-shell/gnome-shell.css" = {
  	source =
  	let
  	theme = pkgs.callPackage ./theme.nix { inherit inputs colors; };
  	in
  	"${theme}/share/gnome-shell/gnome-shell.css";
  	# Reload the extension so the new theme is applied immediately.
  	# (The extension doesn't watch the file for changes.)
  	onChange = "${lib.getExe activator} reload";
  	};
  	# Enable the extension after logging in.
  	configFile."autostart/stylix-activate-gnome.desktop".text = ''
  	[Desktop Entry]
  	Type=Application
  	Exec=${lib.getExe activator} enable
  	Name=Stylix: enable User Themes extension for GNOME Shell
  	'';
  	};
  	}

blocks by setting one of the following:

• stylix.targets.gnome.image.enable = false;

• stylix.targets.gnome.colors.enable = false;

[sylvorg]

Hmm... Would disabling stylix.targets.gnome.colors prevent the colors from base16Scheme taking effect?

[trueNAHO]

Would disabling stylix.targets.gnome.colors prevent the colors from base16Scheme taking effect?

Not entirely, but to some extent. Just try it out.

[sylvorg]

Got it. Any tips on which parts of gnome to look at specifically, or is it generally unclear?

[trueNAHO]

Any tips on which parts of gnome to look at specifically, or is it generally unclear?

Sorry for being confused, but what exactly do you want to look into? If you mean refactoring the core code, then this probably requires investigating the majority of the /doc/ and /stylix/ code.

[sylvorg]

Sorry, sorry; I meant that, if I disabled the gnome colors target, do you know which parts of gnome I should look at for missing colors?

[trueNAHO]

if I disabled the gnome colors target, do you know which parts of gnome I should look at for missing colors?

If you declare

stylix.targets.gnome.colors.enable = false;

it will precisely not declare the following:

stylix/modules/gnome/hm.nix

Lines 102 to 131 in a4406d9

	{
	home.packages = [ extension ];
	dconf.settings = {
	"org/gnome/shell/extensions/user-theme".name = "Stylix";
	"org/gnome/desktop/background".color-shading-type = "solid";
	};
	xdg = {
	dataFile."themes/Stylix/gnome-shell/gnome-shell.css" = {
	source =
	let
	theme = pkgs.callPackage ./theme.nix { inherit inputs colors; };
	in
	"${theme}/share/gnome-shell/gnome-shell.css";
	# Reload the extension so the new theme is applied immediately.
	# (The extension doesn't watch the file for changes.)
	onChange = "${lib.getExe activator} reload";
	};
	# Enable the extension after logging in.
	configFile."autostart/stylix-activate-gnome.desktop".text = ''
	[Desktop Entry]
	Type=Application
	Exec=${lib.getExe activator} enable
	Name=Stylix: enable User Themes extension for GNOME Shell
	'';
	};
	}

What you probably want, is to prevent Stylix from accessing stylix.image with

stylix.targets.gnome.image.enable = false;

such that

stylix/modules/gnome/hm.nix

Lines 17 to 22 in a4406d9

	{
	dconf.settings."org/gnome/desktop/background" = {
	picture-uri = lib.mkIf cfg.useWallpaper "file://${image}";
	picture-uri-dark = lib.mkIf cfg.useWallpaper "file://${image}";
	};
	}

is no longer declared. Then, declare the omitted declarations yourself such that they support your use case. Since there is currently no global stylix.image.enable option, you need to disable stylix.targets.${target}.image.enable everywhere yourself. If modules have no way to disable the stylix.image access, then you probably want to override the relevant declarations with lib.mkForce to support your use case.

[sylvorg]

Ah; got it. Is implementing stylix.wallpaper or modifying atylix.image a good idea, it should I go ahead and close this issue now?

[trueNAHO]

Is implementing stylix.wallpaper or modifying atylix.image a good idea

I think it would be better not to do something like the folllowing:

Unsure whether

stylix.image' =
  lib.mkIf (config.stylix.base16Scheme == null) config.stylix.image;

would generally even make sense.

Instead, it would be better to wait until stylix.image points to a run time directory, if that is even fully possible:

This sounds like a very niche use case that might be resolved once stylix.image points to a run time directory:

• (6) Implement slideshow with post-processing capabilities
  [...]
  • treewide: implement image editor #477 (comment)
  • treewide: implement image editor #477 (comment)

-- #477 (comment)

See #2119 for additional context.

should I go ahead and close this issue now?

Technically, the issue is still unresolved. Let's just leave it open for now.

[sylvorg]

Perfect. Hopefully we can get this resolved soon! I'd love to be able to set all my wallpapers in one go! 😹