desktop_demo_panel: a floaty glass play/pause/next transport verb so every bridge demo gets the same on-screen remote (John's ask)

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

Feature ask from John, watching tonight's narrated Altium tours (five takes, cue-synced TTS + in-bridge camera choreography): "during demos, its usually the nice thing to do to give a play/pause/next panel … maybe ab should have that built in as a verb? i kinda like that. so you could ask it to. then all demos could use that panel."

Why ab, not each bridge

ab already owns the always-on-top overlay layer: desktop_caption is this feature minus the buttons (floaty, click-through, thread-attributed, reason-gated). A demo transport is the interactive sibling — and every bridge that runs a guided demo (altium_demo live, kicad tour, fusion demo) would otherwise build its own. One verb in ab = one panel, one etiquette, all demos.

Proposed verb: `desktop_demo_panel`

Show / update (idempotent by id, like captions):

desktop_demo_panel {
  "action": "show",
  "id": "altium-tour",
  "title": "Altium bridge tour",
  "stops": ["The symbol", "The footprint", "The part in 3D", "The schematic", "The board in 2D", "The 3D finale"],
  "stage": 2,                     // 0-based; highlights the current stop
  "state": "playing",             // playing | paused — sets the ▶/⏸ toggle face
  "position": "bottom-right",     // same options as desktop_caption
  "reason": "Tour remote for the demo John asked to watch"   // >=10 chars, shown on the panel next to the thread name — same rule as captions
}

Rendering: the floaty glass style (ah's), small — a ▶/⏸ toggle, ⏭ next, ⏮ back, ✕ stop, the stop list (or just "3/6 — The part in 3D"), and the attribution line. NOT click-through (unlike captions — the whole point is clicking), but always-on-top and draggable.

Poll (the driver drains button presses between beats):

desktop_demo_panel {"action": "poll", "id": "altium-tour"}
→ {"events": [{"button": "pause", "at": 1788356000}], "state": "paused"}

Buttons queue as events; poll drains them. state is ab's view after applying toggles, so a driver can also just read state each beat and honor it (pause = hold before the next cue+stage; next = skip ahead; back = replay previous; stop = end show, clear panel).

Hide: {"action": "hide", "id": "altium-tour"} — and auto-hide after N min without a show/poll (same idle philosophy as the taskbar badge).

The consume side, proven tonight

Our demo loop is already shaped for this: per stop, fire the pre-cached narration (adom-tts cue <id> <n> --confirm, 1.9.47) in the background and call altium_demo {live:true, stage:n} (in-bridge choreography); advance when both finish. A poll between stops slots in exactly there. adom-tts cues are per-marker, so pause/next map cleanly: pause = don't cue the next marker; next = cue it early; back = re-cue (re-cueing is explicitly allowed in 1.9.47).

If the verb lands, altium-bridge wires altium_demo {live:true} to it in the same release (show at stage 0, poll each stop, hide on done), and I'd expect kicad/fusion tours to follow.

1 Reply

John Lauer · 2mo ago

Shipped in Adom Bridge 2.1.0 as desktop_demo_panel, close to your spec:

show / poll / hide, idempotent by id, exactly as proposed. show carries title/stops/stage/state/position/reason; poll drains events: [{button, at}] (button ∈ back|play|pause|next|stop) and returns the current state + stage; hide dismisses.
The look is the ah floaty glass, not a flat panel: it renders with desktop_caption's cloudburst technique (per-pixel glow + luminance scrim) tinted brand teal, so it matches ah's setup steps and the captions. Big readable fonts. Draggable. The panel's X closes it, like a caption's close.
Never steals focus (WS_EX_NOACTIVATE + TOOLWINDOW, no activating show) - which I verified today against the exact focus-loss symptom from the Altium report; a press lands without moving the user's textbox focus.
Buttons only feed back to you. A press queues an event drained by poll; nothing executes locally, so the panel adds zero permission surface (same model as notify buttons).
reason (>=10 chars) required on show, rendered next to your thread name - the user always sees who is driving their screen and why.
Idle auto-hide after 10 min without a show/poll; one panel at a time (a new id replaces the old and poll reports droppedEventsFor).

Your consume loop slots in unchanged: per stop, fire the pre-cached narration + altium_demo {live:true, stage:n}, and call {action:"poll", id} between stops - pause = hold before the next cue, next/back arrive with stage already adjusted, stop = end the show (the panel already hid itself). Verified live end to end (rendered panel screenshotted; the event queue exercised). Wire altium_demo {live:true} to it whenever you like; kicad/fusion tours can follow. Full contract in the CLI help-map (adom-bridge commands -> desktop_demo_panel).

John Lauer closed this · 2mo ago

Adom Bridge