nixos-icons: allow customizing icon colors

[OsiPog]

This adds options for customization of the colors of the NixOS icons. Previously the colors were hard-coded to the semantically correct base16 values.
As suggested #2155 we also should here add something like colors.override to the target options as people might want to adjust these colors.
The problem is that this module cannot use mkTarget as this is solely an overlay module which as the documentation says should define the target with vanilla NixOS options.
So this PR adds the following options for changing the colors while still communicating that the options are different from the other override options (AI generated options overview):

• stylix.targets.nixos-icons.colors.nix-snowflake-white.white - Replaces the white color in the 'nix-snowflake-white' icon.

  • Type: strMatchingHexColor
  • Default: config.lib.stylix.colors.base05

• stylix.targets.nixos-icons.colors.nix-snowflake.light-blue-darker - Replaces the darker part of light blue color gradient (#699ad7) in the 'nix-snowflake-colours' icon.

  • Type: strMatchingHexColor
  • Default:

    with config.stylix.targets.nixos-icons;
    hexColorAddRgb colors.nix-snowflake.light-blue {
      r = -21;
      g = -23;
      b = -6;
    };

• stylix.targets.nixos-icons.colors.nix-snowflake.light-blue - Replaces the neutral part of light blue color gradient (#7eb1dd) in the 'nix-snowflake-colours' icon.

  • Type: strMatchingHexColor
  • Default: config.lib.stylix.colors.base0C

• stylix.targets.nixos-icons.colors.nix-snowflake.light-blue-lighter - Replaces the lighter part of light blue color gradient (#7ebae4) the 'nix-snowflake-colours' icon.

  • Type: strMatchingHexColor
  • Default:

    with config.stylix.targets.nixos-icons;
    hexColorAddRgb colors.nix-snowflake.light-blue {
      r = 0;
      g = 9;
      b = 7;
    };

• stylix.targets.nixos-icons.colors.nix-snowflake.blue-darker - Replaces the darker part of blue color gradient (#415e9a) in the 'nix-snowflake-colours' icon.

  • Type: strMatchingHexColor
  • Default:

    with config.stylix.targets.nixos-icons;
    hexColorAddRgb colors.nix-snowflake.blue {
      r = -9;
      g = -13;
      b = -21;
    };

• stylix.targets.nixos-icons.colors.nix-snowflake.blue - Replaces the neutral part of blue color gradient (#4a6baf) in the 'nix-snowflake-colours' icon.

  • Type: strMatchingHexColor
  • Default: config.lib.stylix.colors.base0D

• stylix.targets.nixos-icons.colors.nix-snowflake.blue-lighter - Replaces the lighter part of blue color gradient (#5277c3) the 'nix-snowflake-colours' icon.

  • Type: strMatchingHexColor
  • Default:

    with config.stylix.targets.nixos-icons;
    hexColorAddRgb colors.nix-snowflake.blue {
      r = 8;
      g = 12;
      b = 20;
    };

The nix-snowflake-colours icon has a gradient on each lambda to show a subtle shadow on the tips. So the darker and lighter variants of the colors are updated accordingly when the main color (for example stylix.targets.nixos-icons.colors.nix-snowflake.light-blue for changing the light blue lambdas) is updated. But anyone is free to update the gradient colors can do that too. Even using the same function as the module does.

I would like the users to be able to use the hexColorAddRgb function so I just added it as a read-only option to the target. Is that the right procedure here?

closes #2155

• I certify that I have the right to submit this contribution under the MIT license
• Commit messages adhere to Stylix commit conventions
• Theming changes adhere to the Stylix style guide
• Changes have been tested locally
• Changes have been tested in testbeds
• Each commit in this PR is suitable for backport to the current stable branch

[OsiPog]

I'm not sure how to go about these changes. I think they're good in terms of customizability but maybe we should just allow to change the accent colors of the logos and apply the same shading to each.

nixos-icons is in a kinda unique position here as its (with gtksourceview) the only module that only defines an overlay and nothing else.

I think there should be some kind of mkOverlay function or we could extend mkTarget so that it might also take an optional overlay attribute which is handled the same way as config. So when given a function that takes colors as an argument the appropirate options in stylix.targets.<name> (colors.enable and colors.override) are generated. So that it doesn't differ from the configuration of other targets.

I was about to write something that simulates the behaviour of colors.override for this target but still having all the code for that in the nixos-icons module. But I decided not do that as we should communicate to the users that this target works different from the others.

Would it be a good idea to extend mkTarget in way that it works with overlays? Or is the risk of breaking everything too high? Should I rather simulate colors.override for this module eventhough the code will not be the same as in the other targets that provide colors.override?

Tell me what you think :)

[0xda157]

I think there should be some kind of mkOverlay function or we could extend mkTarget so that it might also take an optional overlay attribute which is handled the same way as config. So when given a function that takes colors as an argument the appropirate options in stylix.targets.<name> (colors.enable and colors.override) are generated. So that it doesn't differ from the configuration of other targets.

this was previously attempted in #1427

Would it be a good idea to extend mkTarget in way that it works with overlays? Or is the risk of breaking everything too high?

I think this would be good to attempt again, although not a part of mkTarget, instead reusing functionality similar to #1427

[trueNAHO]

I think there should be some kind of mkOverlay function or we could extend mkTarget so that it might also take an optional overlay attribute which is handled the same way as config. So when given a function that takes colors as an argument the appropirate options in stylix.targets.<name> (colors.enable and colors.override) are generated. So that it doesn't differ from the configuration of other targets.

this was previously attempted in #1427

Would it be a good idea to extend mkTarget in way that it works with overlays? Or is the risk of breaking everything too high?

I think this would be good to attempt again, although not a part of mkTarget, instead reusing functionality similar to #1427

The mkTarget module system is already expressive enough to represent overlays. #2174 leverages the existing mkTarget logic and removes the separate overlay concept.

Tell me what you think :)

This PR is essentially what would have happened without our custom mkTarget module system. If #2174 works, this PR should be superseded by it.