Initially, I was using a weird combination of options in order to apply
my theme dynamically. I was setting a read-only option from inside my
modules, which was then used in every application that required it. What
I ended up doing is refactoring everything in order to be inside of my
theme module, and automatically configured when enabled, without doing
any mkMerge/mkIf shenanigans in my other pieces of configuration. This
is healthier, although it should be split up as the theme/default.nix
got quite big.
Implemented notifications with SwayNotificationCenter, as well as theming using
the custom theme module. Some Waybar code had to be updated too, and was
also simplified in order to be more consistent with the new
SwayNotificationCenter implementation.
I decided to refactor how the theme module works. The idea is, that I
wanted originally a module that I could give a base16 scheme name to,
and use that globally in my config. However, scheme only took the base16
scheme name without any checks, which was pretty bad. I ended up
creating a new option, schemeName, that scheme is computed from. It then
makes the whole configuration cleaner, and avoids long inputs
interpolations with the scheme name.
I decided to import my custom lib as lib' as it makes it easier to read
and differentiate from lib. I also removed unnecessary imports from my
mkSystem function (that I actually put directly inside
hosts/default.nix, as that made more sense), since system is not needed
anymore (already set in hardware-configuration.nix), and the only
required argument is inputs, that will be then parsed automatically by
nixosSystem.
Using absolute path imports is apparently a horrible idea since that
just messes up the store, and will bring a lot of issues since that
copies it to the store separately.