wispd should provide a scriptable control CLI, similar in spirit to makoctl, for querying and
controlling the running daemon.
Why
A control CLI is useful for:
- keybindings / compositor integration
- scripting and automation
- debugging and inspection
- interacting with live notifications, notification center state, and history without relying only on
UI
Initial scope
wispctl should likely cover at least:
- list — list current/live notifications
- dismiss — dismiss one / current / all notifications
- invoke — invoke default or named action for a notification
- reload — reload daemon config
- history — inspect stored notification history
Design notes
- unlike makoctl, a built-in menu subcommand likely does not make sense here
- instead, wispctl should expose solid query/action primitives and machine-readable output so users
can compose external selectors themselves
- wispctl should be designed around wispd’s richer model:
- live popup stack
- notification center
- history
Output / API expectations
- human-readable output by default
- --json for scripting/integration
- stable selection semantics by:
- notification id
- current/topmost/latest where applicable
- app/group later where applicable
Likely implementation areas
- a daemon control API/IPC surface in wisp-source / wispd
- new wispctl binary
- command/query paths for live, center, and history state
Acceptance criteria
- users can query and control the running daemon from the CLI
- core notification actions (list, dismiss, invoke, reload) are available
- history inspection is available
- machine-readable output is supported for scripting
wispd should provide a scriptable control CLI, similar in spirit to makoctl, for querying and
controlling the running daemon.
Why
A control CLI is useful for:
UI
Initial scope
wispctl should likely cover at least:
Design notes
can compose external selectors themselves
Output / API expectations
Likely implementation areas
Acceptance criteria