From John (2026-08-14). Building the web-control demo surfaced that ab (and its demos) should NOT hand-assemble your bridge's commands to show off Blender - I am not the expert on Blender's capabilities, and I keep getting it subtly wrong (wrong window, wrong file type, wrong workflow). The bridge is the expert. So please own a self-contained demo verb.
Requested: a long-running blender_demo verb that showcases Blender and reports STRUCTURED PROGRESS.
What it does:
- Runs a representative, visible workflow for Blender end-to-end, using sample data the BRIDGE provides or creates (a sample project / library / design), because a caller has nothing to open otherwise. e.g. open a sample .blend, show the 3D viewport, and a render or material view. Pick whatever best shows Blender off.
- Returns structured PROGRESS so a web front-end can draw a real progress bar - not a spinner. Concretely, on start report an ESTIMATE (e.g.
{estimatedSec: 45}), and as it runs report {percent, elapsedSec, estimatedSec, step, stepLabel} so the UI can render "opening the board... 60% (27s of ~45s)". You know your app's timings; ab and the browser do not.
- Returns structured RESULT: the screenshot ARRAY (base64) of the resulting state (all of Blender's relevant windows - parent + children) plus the logical state (what opened). This is the
blender_state-style payload from the related suggestion, as the demo's final result.
- Is idempotent-ish and safe to re-run (close/reset first if needed), and cleans up or leaves Blender in a sane state.
Why the bridge owns it (not ab):
- You can RALPH-TEST it yourself against real Blender and guarantee it returns something perfect, instead of ab guessing which verbs to chain.
- You own the sample data + the exact window identities + the real timings.
- ab stays generic: it just calls
blender_demo, relays your progress, and renders your screenshots. It plugs straight into ab's streaming endpoint (POST /command/stream) - if you can emit progress incrementally (or expose a blender_demo_progress poll verb returning the same {percent, elapsedSec, estimatedSec, step}), ab streams it to the browser live and the front-end draws the bar.
This is the natural home for the blender_state (screenshot array) and verbDurations (timing) suggestions filed separately - a demo verb needs both. Ship it when convenient; it's what makes a "click a button, watch Blender do a real thing with a progress bar" demo possible without ab pretending to know your app.
Environment: Adom Bridge 2.0.37. The web-control demo (https://wiki.adom.inc/api/v1/pages/adom-bridge/files/web-control-demo.html) is the consumer.