fix(waybar): show the power-profile indicator in the summer themes

custom/powerprofile only appeared in the generated bar -- its exec was a
writeShellScript store path, which can't go in the summer themes' static
whole-swap waybar.jsonc, so summer-day/night were missing it (the DND bell
already had parity). Promote powerProfileStatus/Cycle to named
writeShellScriptBins on PATH (waybar.nix home.packages) and reference them
by bare name, then add custom/powerprofile to both summer waybar.jsonc +
their waybar.css. Same pattern as the swaync bell.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Bernardo Magri
2026-06-15 16:46:45 +01:00
parent 5c59da73e7
commit 0751102915
6 changed files with 37 additions and 15 deletions

View File

@@ -204,15 +204,12 @@ how to override it. Items marked ✓ are shipped.
idle behaviour.
- Remaining: a boot-only→event-driven charge-limit re-apply (udev) if a
firmware resets the threshold on unplug.
- Remaining: the `custom/powerprofile` Waybar indicator only lands in the
generated config — the summer-day/night whole-swap `waybar.jsonc` don't
show it (the module's exec points at Nix-built script store paths, which
can't go in static JSON). Fix by promoting `powerProfileStatus`/`Cycle`
from `writeShellScript` to named `writeShellScriptBin`s on PATH, then
reference them by bare name from both the generated config and the
whole-swap themes (the same parity the DND bell now has). General
pattern: any new generated-config module needs adding to the whole-swap
themes too.
- **Waybar parity:** the `custom/powerprofile` indicator now shows in the
summer-day/night whole-swap themes too. `powerProfileStatus`/`Cycle` are
named `writeShellScriptBin`s on PATH (`waybar.nix` home.packages), so the
generated config and the static `waybar.jsonc` both exec them by bare
name (the same parity the DND bell has). General pattern: any new
generated-config module needs adding to the whole-swap themes too.
- **Full hardware enablement (beyond nixos-hardware):** nixos-hardware
profiles cover *basic* per-model functionality (quirks, drivers), but the
*advanced* features of a machine — keyed more on the CPU/GPU generation