Add a 'stylix.enable' option to enable or disable all Stylix modules in
order to resolve issues similar to [2].
To align with the default 'lib.mkEnableOption' [1] behavior,
'stylix.enable' defaults to 'false'.
BREAKING CHANGE: Stylix is disabled by default. To enable it, use:
stylix.enable = true;
[1]: https://github.com/NixOS/nixpkgs/blob/23.11/lib/options.nix#L91-L105
[2]: https://github.com/danth/stylix/issues/216
Co-authored-by: Daniel Thwaites <danthwaites30@btinternet.com>
Co-authored-by: Jalil David Salamé Messina <jalil.salame@gmail.com>
Co-authored-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
The attrset is used heavily in styllix's modules, but the docs don't contain even a top-level explanation of its value. Though you can gather most it from skimming `base16.nix`, I think stylix should provide an entry point for users, interested in using their color schemes outside of stylix. I base this assumption on personal anecdote of people not having a good understanding of exported values even after extended usage and implementing parallel parsing logic for color scheme files.
The function implements a fairly popular feature and is pretty old, but never gets mentioned in the docs. In fact, I only found it by randomly going through the sources. As a result, a person I spoke to wrote the section above describing a re-implementation of the function, which does work but doesn't need to be the default approach.
This change will improve discoverability of the codebase and direct users to a more standardized implementation.
P.S. `base16-schemes` changed `catppuccin.yaml` to a couple of variant themes, which is represented in this commit.
I've noticed quite a few pull requests are being submitted with formats
such as feat(abc): or target: at the start of the message.
It will be helpful to have a specific format for this to keep things
consistent.
The Tinted Theming repository is now packaged in Nixpkgs, so we
don't need to list other ways to obtain it.
Also simplified the links to the preview as `$XDG_CONFIG_HOME`
is rarely modified.
This was more of a developer tool than part of the documentation, so it
makes sense to keep it off the main site. Also when modifying the
palette generator, the documentation on the site would become out of
sync with local changes anyway.
