In our current approach the user has to include home-manager themselfs in their config. If they dont, they will become weird errors. Additionally some folks might not even use home-manager and I think it would be great if the setup was as easy from them as for the rest.
Therefore I added home-manager as a flake input and included it in our config directly.
The only drawback is that now someone who includes home-manager themselfs has to pin the home-manager input for Nixos95 (which I also mentioned in the README.
~ gytic
added both a home-manager and 'minimal configuration'.
They can be built and testet in this repo via:
- nixos-generate-config --dir example/default # or example/home-manager
- nix build path:./example/default#nixosConfigurations.default.config.system.build.toplevel # or path:./example/home-manager#...
the flake.lock and hardeware-configuration is ignored to prevent accidental commitment of the hardware-configuration (and get the freshes packages when somebody might use these configs as templates
For users that already use home-manager, this shouldn't change anything (they just have to pin the home-manager input to their own version).
However for users that currently do not use home-manager this will allow them to not care about it.
This way, home-manager will become an 'implementation detail'
Enable the power bar to get a quick overview of the remaining battery.
As the bar is not a 'perfect theme fit' (imo) there is an option to disable it (default: enabled)
as well as some QoL options to change the critical and warning state as well as some display colors
xfwm4 stores important default keybinds inside the "custom" section.
These important keybinds were removed in commit d5458a9fcf
as I thought they would be added automatically back in. This regression
is now reverted.
when using nixos95 from another flake, the other flake will take over the path of inputs.self and therefore
break the paths.
We can fix this by navigating to the root with relative notation and contiuning from there
