[Feature request]: Support for toggling between Light and Dark polarity

[TheColorman]

I like synchronizing my system color to the sunset and sunrise, but that's not possible with Stylix unless I do a nixos rebuild. I'd love for Stylix to generate both a dark and a light polarity theme on rebuild, for the OS to then be able to switch between them using a program like baduhai/Koi or oskarsh/Yin-Yang (or even built in to Stylix itself?)

Manual/dynamic switching between light and dark themes is increasingly popular, so I think Stylix supporting it would make a lot of sense, though I'm not sure how much effort it would take to implement such a feature.

[danth]

This is difficult to implement since only a very small number of apps can switch based on a toggle (such as in GNOME), and only about half of apps have automatic reload if we were to change their config on a timer.

[trueNAHO]

https://github.com/danth/stylix/issues/63 could be extended in the future to change wallpapers with a certain color palette based on the time.

[BhasherBEL]

One way to achieve it, at least for the apps that works with "hot reload", could be to use specialisation. A very basic example would be:

    stylix = {
      enable = true;
      image = ./assets/mountains_dark.jpg;
      polarity = "dark";
      base16Scheme = "${pkgs.base16-schemes}/share/themes/catppuccin-macchiato.yaml";
    };

    specialisation.day.configuration = {
      stylix = {
        image = lib.mkForce ./assets/mountains_light.jpg;
        polarity = lib.mkForce "light";
        base16Scheme = lib.mkForce "${pkgs.base16-schemes}/share/themes/catppuccin-latte.yaml";
      };
    };

[trueNAHO]

One way to achieve it, at least for the apps that works with "hot reload", could be to use specialisation.

Feel free to submit a PR adding this to docs/src/tricks.md.

[no-mood]

One way to achieve it, at least for the apps that works with "hot reload", could be to use specialisation. A very basic example would be:

    stylix = {
      enable = true;
      image = ./assets/mountains_dark.jpg;
      polarity = "dark";
      base16Scheme = "${pkgs.base16-schemes}/share/themes/catppuccin-macchiato.yaml";
    };

    specialisation.day.configuration = {
      stylix = {
        image = lib.mkForce ./assets/mountains_light.jpg;
        polarity = lib.mkForce "light";
        base16Scheme = lib.mkForce "${pkgs.base16-schemes}/share/themes/catppuccin-latte.yaml";
      };
    };

Do specialisation work for you? Can't get the "hot reload" as many things (including GTK apps) don't switch unless i close and re-open them

[trueNAHO]

Do specialisation work for you? Can't get the "hot reload" as many things (including GTK apps) don't switch unless i close and re-open them

Hot reload support is application dependant. See https://github.com/danth/stylix/discussions/371 for more information.

[TheColorman]

@BhasherBEL just tried it out, seems to work pretty nicely! Do Stylix options such as config.lib.stylix.colors also get updated when they are used outside of the specialisation?

[BhasherBEL]

@BhasherBEL just tried it out, seems to work pretty nicely! Do Stylix options such as config.lib.stylix.colors also get updated when they are used outside of the specialisation?

Specialisations can be used multiple ways, but literally build a new system for every specialisation, so yeah, it should not be a problem.

[TheColorman]

If anyone's interested I've written a small service that uses heliocron to automatically switch polarity on sunset/sunrise. It can probably be improved, but it does the job: TheColorman/nixcfg/modules/profiles/stylix/default.nix

I'm still not too happy about having to do an entire nixos-rebuild just to switch theme, as it feels a bit overkill, but this works for now.

[trueNAHO]

If anyone's interested I've written a small service that uses heliocron to automatically switch polarity on sunset/sunrise. It can probably be improved, but it does the job: TheColorman/nixcfg/modules/profiles/stylix/default.nix

This is a great PoC. Thanks for sharing!

I'm still not too happy about having to do an entire nixos-rebuild just to switch theme, as it feels a bit overkill, but this works for now.

Aside from replacing nixos-rebuild with Nix specialisations and replacing the service loop on success with a simple infinite Bash loop to improve logging, this looks mostly good.

[TheColorman]

Aside from replacing nixos-rebuild with Nix specialisations and replacing the service loop on success with a simple infinite Bash loop to improve logging, this looks mostly good.

Issue with specialisations is that specialisations can't refer to each other, so assuming there was both a light and a dark specialisation, the /run/current-system/specialisation/ directory is empty after you switch to one of the specialisations, and the only way to switch to the other specialisations is a full nixos-rebuild, apparently due to some issues with infinite recursive references.

As far as I understand, activating the specialisation through /run/current-system/specialisation/ is functionally the same as running nixos-rebuild test --specialisation.

[noahfraiture]

Hello, is there any news since the POC ? It looks great and it would be really neat ! In the mean time, except for the time needed, is there disadvantage to rebuild ? If it upgrade isn't it possible to disable the upgrade to be sure to make the minimal number of new store ?

[danth]

In the mean time, except for the time needed, is there disadvantage to rebuild?

Some targets don't reload their theme until the app is restarted, so the new theme may not be applied consistently throughout the system. This is something we cannot fix without modifying the apps themselves to support hot reloading.

If it upgrade isn't it possible to disable the upgrade to be sure to make the minimal number of new store?

If you use specialisations, these are pre-built, so only the activation stage of the rebuild actually happens at the time you apply the specialisation. This means that switching to a specialisation won't pull in package updates.

[noahfraiture]

In the mean time, except for the time needed, is there disadvantage to rebuild?

Some targets don't reload their theme until the app is restarted, so the new theme may not be applied consistently throughout the system. This is something we cannot fix without modifying the apps themselves to support hot reloading.

Yes of course, but that's another problem

If it upgrade isn't it possible to disable the upgrade to be sure to make the minimal number of new store?

If you use specialisations, these are pre-built, so only the activation stage of the rebuild actually happens at the time you apply the specialisation. This means that switching to a specialisation won't pull in package updates.

Oh thank you, I didn't know about specialisation, I'll search for more information about it