Open jamesbaw1 opened 4 months ago
There are mkBefore
and mkAfter
functions in lib
. These change the order in which option definitions are merged; for example the two definitions "a"
and mkBefore "b"
would be guaranteed to merge as "ba"
.
If we add mkBefore
to any CSS defined by Stylix, then we can guarantee that CSS added by the user will be applied later without needing to create another option.
So,
config = lib.mkIf (config.stylix.enable && config.stylix.targets.waybar.enable) {
programs.waybar.style = # ...
};
would become
config = lib.mkIf (config.stylix.enable && config.stylix.targets.waybar.enable) lib.mkBefore {
programs.waybar.style = # ...
};
?
I'm relatively new to the nix language, so sorry if I'm missing the obvious.
I believe the mkBefore
needs to go on the programs.waybar.style
option specifically, so it should be programs.waybar.style = lib.mkBefore ...
Ah, okay. I'm still getting my setup in order, so it may take a while for me to submit a PR.
Currently, it's quite difficult to add CSS on top of the CSS generated by Stylix. The main issue is when it comes to overwriting CSS rules, because the user-defined CSS (for example programs.waybar.style in home.nix) is applied before the CSS generated by Stylix.
Perhaps we could add an extraCss option to more (hopefully eventually all) targets, as it is already a feature for GTK, and would be as simple (I think?) as appending the text in the user-defined extraCss to the CSS that is already being applied to the target. For example:
This could also act as a band-aid solution to #429 and maybe some other feature requests concerning CSS, as users could simply overwrite existing CSS rules.
The other option may be to somehow get the user-defined programs.waybar.style to apply after Stylix's version, but I'm not an expert at nix, and I don't know how feasible this is. It's also not as universal a solution.