Per-program theme selection

[jeanlucthumm]

I would like to override the base** colors on a per program basis instead of having them all pulled from a global config.lib.stylix.colors.

Stylix is becoming a repo of "base16 -> how to apply the theme per program", but that mapping is not exposed in a reusable way. So I either have to choose between the same theme for every program, or replicating the modules/ directory in my own flake.

[trueNAHO]

IIRC, a similar request has already been in the past. For reference, I added this task to the current roadmap:

• (5) Support individual module customizations 7

-- #534 (comment)

[danth]

A good implementation IMO would be to move the polarity, image, base16Scheme, etc. options into a submodule type, and use that type in new stylix.theme and stylix.targets.«name».theme options, with the latter falling back to the former if it's not defined.

[jeanlucthumm]

@danth FYI I'm working on something that does the base16 input to program mapping more directly:

https://github.com/jeanlucthumm/nix-maptheme

But still debating whether it's worth pursuing this or opening a PR here.

[trueNAHO]

FYI I'm working on something that does the base16 input to program mapping more directly:

https://github.com/jeanlucthumm/nix-maptheme

But still debating whether it's worth pursuing this or opening a PR here.

Will the following task from the Roadmap resolve this issue:

• Is this a problem with stylix or with home-manager?

It is an already acknowledged integration limitation between Stylix and Home Manager:

I wanted to override a few colors for Gnome (without recreating all the needed derivations), but it looks like that the template is hardcoded.

Ideally, we would upstream (NixOS, Home Manager, or nix-darwin) relevant options to seamlessly integrate Stylix into external Nix code.

There's this relevant thread: #159 about moving these templates out-of-tree. Would a PR for separating the mustache template to a different repo be acceptable here?

The future Vim highlight groups would allow us to get rid of mustache templates:

the roadmap eventually causes Stylix to implement all templates without relying on external dependencies

-- #567 (comment)

[...]

Are the patches really suitable for upstreaming though? It contains a lot of stylix-specific changes, like removing dark mode. The style sheet itself is also fairly opinionated and custom, which is not something I usually see upstream.

My idea was to move our string injection architecture

xdg.configFile."<MODULE>".text = "<KEY>=<VALUE>";

upstream, and then we only use its interface:

programs.<MODLE>.extraConfig."<KEY>" = "<VALUE>";

This centralizes the string injection upstream and hopefully gets rid of override issues:

the use of extraConfig might cause other potentially related issues. As discussed in #159 (comment), it makes it harder to override options, and as discussed in #388 (comment), it makes it easier to accidentally override Stylix options.

-- #395

-- NAHO, "Overriding Gnome template"

• Is there any way around this?
• How can this be solved?

Unless you copy-paste and slightly modify the current Stylix module implementation, I am unaware of a reliable solution before the previously mentioned limitations have been resolved. Depending on the configuration format, lib.mkAfter could be used.

-- NAHO, "Using stylix with home.file"