Virtual apps: 2–3 stateful ticking apps
The "background processes" that make the demo feel alive — each holds state, ticks on the shared clock, and responds to deck presses.
Apps (start with these)
- Music player —
position advances while playing; emits media_state + chrome_media; responds to media_command (play/pause/next/prev). The progress bar keeps moving while you're on another deck.
- Sensor source — CPU/temp/etc. meters that wander deterministically; emits
widget_update.
- One more (lighting or a timer) so switching between apps feels meaningful.
Interface
Each app implements the virtual-app abstraction from the foundation issue: tick(dt) to advance state and handle(clientMessage) to react to presses/commands.
Two payoffs, not one
- Drives the demo.
- Doubles as deterministic test fixtures for the focus-driven app-switching logic, which is otherwise painful to test. Keep them deterministic to preserve this.
Part of the mocked-demo epic. Depends on the MockDaemon foundation.
Virtual apps: 2–3 stateful ticking apps
The "background processes" that make the demo feel alive — each holds state, ticks on the shared clock, and responds to deck presses.
Apps (start with these)
positionadvances while playing; emitsmedia_state+chrome_media; responds tomedia_command(play/pause/next/prev). The progress bar keeps moving while you're on another deck.widget_update.Interface
Each app implements the virtual-app abstraction from the foundation issue:
tick(dt)to advance state andhandle(clientMessage)to react to presses/commands.Two payoffs, not one
Part of the mocked-demo epic. Depends on the MockDaemon foundation.