Module notify_handlers

Expand description

RPC surface of the notification Router — docs/specs/SPEC_OS_NOTIFICATIONS_SYSTEM_2026_09_24.md §3.3.

notify.emit renderer → router: a pane event the renderer is the authority for (turn outcome, waiting-for-input).
notify.focus renderer → router: this window’s focus state.
notify.ack presenter → router: user clicked / dismissed a toast.
notify.test Settings “Send test notification”.
notify.takeactivation new window → router: a click that arrived while no window was open.
block.reveal any renderer → router: reveal a block that lives in ANOTHER window. Same target resolution as a toast click, so it lives with the Router, which knows which windows are open (SPEC_REVEAL_BLOCK_ONE_PATH_2026_09_27.md §4.3).

conn_id is captured per connection so focus reports are keyed by window and dropped on disconnect (see websocket.rs’s disconnect path).

Structs§

BlockRevealParams
BlockRevealResult
NotifyAckParams
NotifyAckResult
NotifyAttentionResult: notify.attention: the calls to action srv holds open now (backend/user_attention.rs), each as its userattention event’s data.
NotifyEmitParams
NotifyFocusParams
NotifyNoArgs
NotifyOk
NotifyTakeActivationParams
NotifyTakeActivationResult

NotifyPaneEvent: Pane-level events the renderer reports. question accompanies input_waiting only; the router redacts it (§9.2).

activate_in_stored_layout 🔒: LayoutStackActivate through the reducer, then mstore — the same dispatch → apply → publish shape as pane.moveTab. Best-effort: the renderer switches the pane itself on block:reveal, so a reducer that can’t apply it (no tree for the tab yet) only costs the head start.
register_notify_handlers
reveal_block 🔒: block.reveal: resolve the block’s tab and open window like a toast click, make the block its pane’s visible tab in the STORED layout (so a window that loads the tab fresh already shows it), then tell only that window’s renderer to reveal it (block:reveal). A workspace open in no window is out of scope: found: false, nothing changed.
router_for 🔒