stylix: refactor stylix.icons to use `{ name, package }` type

[trueNAHO]

I assert that this feature request is relevant for Stylix

• [x] I assert that this is not a duplicate of an existing feature request.

Description

The

stylix.icons = {
  dark = "<DARK_THEME>";
  enable = true;
  light = "<LIGHT_THEME>";
  package = pkgs."<PACKAGE>";
};

interface introduced in commit f3c2f5a1796c ("stylix: set GTK icon theme (#603)") is cumbersome and should be replaced with something like:

stylix.icons = {
  dark = {
    name = "<DARK_THEME>";
    package = pkgs."<DARK_PACKAGE>";
  };

  enable = true;

  light = {
    name = "<LIGHT_THEME>";
    package = pkgs."<LIGHT_PACKAGE>";
  };
};

The { name, package } type is the same as the one proposed in https://github.com/nix-community/stylix/issues/366#issuecomment-3067360491 for stylix.fonts."<TYPE>"."<FONT>" = { inherit name package };. Using the same { name, package } type for both options would result in a more coherent interface.

I assume name cannot generally be inferred from package, meaning that we need to provide both.

Notify maintainers

No response

[danth]

Having separate options for light and dark themes seems redundant at least for the time being, since the rest of Stylix only supports setting a single theme, so presumably only one of them can ever be active. The current implementation just picks the option matching stylix.polarity, or else the first one which is defined, and the other option is discarded.

[trueNAHO]

Having separate options for light and dark themes seems redundant at least for the time being, since the rest of Stylix only supports setting a single theme

The current interface does not really allow using packages that do not provide both dark and light themes. The simplest end-user workaround is to ignore the other theme, although this limits the stylix.polarity functionality:

stylix = {
  icons = {
    dark = "<DARK_THEME>";
    enable = true;
    package = pkgs."<PACKAGE>";

    # Implicitly do not declare stylix.icons.light due to the current polarity:
    #
    #     light = throw "stylix.icons.light should never be evaluated";
  };

  # The following declaration breaks Stylix:
  #
  #     polarity = "light";
  polarity = "dark";
};

Otherwise, one of the themes is duplicated, as mentioned in 1 2:

stylix = {
  icons = {
    dark = "<DARK_THEME>";
    enable = true;
    package = pkgs."<PACKAGE>";
    light = "<DARK_THEME>"; # Duplicate of stylix.icons.light.
  };

  # The following declaration does not break Stylix, but causes an undesired
  # stylix.icons theme:
  #
  #     polarity = "light";
  polarity = "dark";
};

Obviously, requiring end-users to manually merge pkgs."<DARK_PACKAGE>" and pkgs."<LIGHT_PACKAGE>" into a single pkgs."<PACKAGE>" package is cumbersome.

[danth]

Polarity is just an input to guide the palette generator - it could be set to "either" or it could not match the color scheme at all, particularly when the user has selected one manually.

The current interface does not really allow using packages that do not provide both dark and light themes.

This seems correct to me - we don't have options for a light and dark wallpaper, for example.

Switching between settings at build time is usually handled externally, for example by writing a module for each theme and only importing the currently desired theme. The icon theme option is an outlier in this regard.

[trueNAHO]

Polarity is just an input to guide the palette generator - it could be set to "either" or it could not match the color scheme at all, particularly when the user has selected one manually.

IIRC, https://github.com/nix-community/stylix/pull/892 removes the "either" polarity.

The current interface does not really allow using packages that do not provide both dark and light themes.

This seems correct to me - we don't have options for a light and dark wallpaper, for example.

Switching between settings at build time is usually handled externally, for example by writing a module for each theme and only importing the currently desired theme. The icon theme option is an outlier in this regard.

Indeed. So the correct inferace should be:

stylix.icons = {
  enable = true;
  name = "<NAME>";
  package = pkgs."<PACKAGE>";
};

I suppose this would change again once we get to

• [ ] (7) Support automatic polarity switch based on sunset and sunrise
  • https://github.com/nix-community/stylix/issues/447#issuecomment-2351837256

-- https://github.com/nix-community/stylix/issues/534

although this will still take a while.