feat: add theme modality support for light/dark themes

[rawkode]

I don't know if this is something the project is looking to adopt, but I forked and made this work for Ghostty for my own experiment and plan to add support for more modules.

Sharing for feedback and to hopefully upstream.

Related #447

---

Add support for configuring separate light and dark themes that can be used by applications supporting automatic theme switching. This includes:

• New theme.light and theme.dark configuration options
• defaultTheme option to control fallback for single-theme apps
• Full backward compatibility with existing configurations
• Ghostty integration with automatic light/dark theme switching
• Documentation for theme modality configuration and migration

---

• 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

[trueNAHO]

I don't know if this is something the project is looking to adopt

Yes, adding polarity switching is on the roadmap, although your proposal is not a general automatic solution:

• (7) Support automatic polarity switch based on sunset and sunrise
  • #447 (comment)
  • #1863 (comment)

-- #534

Related #447

Consider taking a look at the following existing discussions:

• #1855
• #1863
• #892 (comment)

Also, #892 might simplify stylix.polarity by removing the non-decisive "either" variant.

• New theme.light and theme.dark configuration options

The stylix.theme.{dark,light}.icons.package top-level namespace seems to be better than the previously proposed stylix.theme.icons.{dark,light}.package API:

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

  enable = true;

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

-- #1855 (comment)

As mentioned in #892 (comment), stylix.theme is too broad and should be replaced with something like stylix.colors.

• defaultTheme option to control fallback for single-theme apps

Would everyone not just treat this exactly like stylix.polarity, making this option redundant and confusing?

• Full backward compatibility with existing configurations

Thanks for going the extra mile of making this backward compatible, but since the following roadmap tasks are likely already going to introduce slight breaking changes, it might be better to accept breaking changes in order to keep the interface and implementation simple:

• (4) Extend and standardize color scheme
  [...]
• (6) Implement slideshow with post-processing capabilities
  [...]
• (7) Support automatic polarity switch based on sunset and sunrise

-- #534

However, the extent of the breaking change can be substantially reduced by aliasing the existing options into stylix.theme.dark with lib.mkRenamedOptionModuleWith.

• Documentation for theme modality configuration and migration

Instead of adding a new documentation page, the existing documentation should be appropriately updated. I am aware this is a PoC, but this should eventually be resolved.

[trueNAHO]

• Ghostty integration with automatic light/dark theme switching

AFAICT, this is not automatically switching polarity. Do you mean that this exposes theme variants to the application that can at run time be manually selected? In this case, this would be a subset of #447, except that the theme variants are not exposed to the application, although this would be mostly irrelevant in that case.

[rawkode]

For applications that support xdg-desktop-portal-gtk theme, meaning they accept a config that supports switching between two themes.

For any application that needs to toggle between two themes, they'd need to integrate via darkman scripts. We could likely configure these, assuming we're happy to loop in darkman.

Other applications would fallback on the defaultTheme/polarity.