refactor: power-confirm via PowerAction table (v0.10.1)

Replace the two hand-wired reboot/shutdown handlers and the loose-param show_power_confirm with a PowerAction table + create_power_button factory, mirroring moonset's ActionDef pattern. Couples icon/prompt/error/action so a mismatched prompt/action pair is unrepresentable. Restore the in-flight re-trigger guard via power_box.set_sensitive(false) (re-enabled on failure), superseding the v0.10.0 "no guard" tradeoff.
2026-06-02 14:31:31 +02:00
parent 3c34b4ec25
commit 030f8c62a6
4 changed files with 106 additions and 60 deletions
@@ -1,5 +1,12 @@
 # Decisions

+## 2026-06-02 – Align power-confirm to moonset's ActionDef pattern (v0.10.1)
+
+- **Who**: ClaudeCode, Dom
+- **Why**: Code review of v0.10.0 flagged the power-confirm code (ported verbatim from moonlock) as lower-altitude than moonset's: two near-identical reboot/shutdown handlers and a `show_power_confirm` taking loose `message`/`action_fn`/`error_message` params that can drift apart. moonset already solved this with an `ActionDef` table + button factory.
+- **Tradeoffs**: A `PowerAction` struct + `power_actions()` table + `create_power_button` factory is slightly more machinery for just two actions, but couples icon/prompt/error/action into one value (mismatch becomes unrepresentable) and makes a third action a one-line table entry. Kept in lockstep with moonlock (same change landed there). Did NOT touch `confirm_box: Rc<RefCell<Option<gtk::Box>>>` — moonset uses the same, it is the shared convention.
+- **How**: Replaced the two hand-wired handlers with a loop over `power_actions()`; `show_power_confirm`/`execute_power_action` now take `PowerAction` (Copy) instead of three loose strings. Re-introduced the in-flight re-trigger guard via `power_box.set_sensitive(false)` (re-enabled on failure) — this restores the protection that v0.10.0 dropped, superseding that entry's "no guard" tradeoff.
+
 ## 2026-06-02 – Inline power confirmation before reboot/shutdown (v0.10.0)

 - **Who**: ClaudeCode, Dom