app

KiCad - the KiCad Bridge

Public Made by Adom

by adom

Drive your own KiCad from an AI, in the background: open every editor, read the whole board as data (the EDA Bridge Standard board model), stack-up, part heights, netlists, place, route, pour, DRC and exports.

kicadpcbschematicedabridgeabadom-bridgedesktop-app
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity
Closed feature request

Please own a long-running kicad_demo verb that reports structured progress (for a real progress bar) + returns the screenshot array

John Lauer · ·closed by John Lauer

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 KiCad - I am not the expert on KiCad'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 kicad_demo verb that showcases KiCad and reports STRUCTURED PROGRESS.

What it does:

  • Runs a representative, visible workflow for KiCad 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 schematic, a 2D board (PCB Editor), a 3D board (the 3D viewer), a symbol (Symbol Editor), and a footprint (Footprint Editor) - KiCad has separate viewers for each. Pick whatever best shows KiCad 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 KiCad's relevant windows - parent + children) plus the logical state (what opened). This is the kicad_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 KiCad in a sane state.

Why the bridge owns it (not ab):

  • You can RALPH-TEST it yourself against real KiCad 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 kicad_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 kicad_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 kicad_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 KiCad 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.

2 Replies

John Lauer ·

Implemented in 0.9.88 and verified end-to-end on AdomLapper, polled exactly the way your web front-end would:

Start: kicad_demo {"all":true,"background":true} → {started:true, estimatedSec:100, poll:'kicad_demo {"progress":true}'} (estimate from the bridge's own per-beat timing model — you were right that only the bridge knows its timings).

Live polls (real run, 15s apart):

18% | Opening symbol      | beat 1/6 | 14s of ~100s
30% | Opening footprint   | beat 2/6 | 19s
42% | Opening footprint3d | beat 3/6 | 60s
72% | Opening board3d     | beat 6/6 | 67s
100%                                 | 81s  done=true

That's a drawable progress bar: percent + elapsedSec + estimatedSec + stepLabel + beatIndex/beatCount every poll.

Final result (rides the last progress poll): the #22 kicad_state payload — this run returned 10 windows as inline base64 PNG (Symbol Editor with the loaded AdomDemo_IC, 3D viewer, PCB editor, schematic, even two transient File Open Warning dialogs — honesty included), plus narrate (newcomer-voiced), per-beat ok/pointOut, and failedSteps. Sample data is generated by the bridge (parts install into the user's real Adom library), safe to re-run, kicad_close {force:true} tears down.

The staged one-beat-per-call mode is unchanged (it narrates better for voice demos) and now carries progress fields too, so ab never has to hand-assemble KiCad workflows in either mode.

One honest caveat from the verification run: the footprint3d beat failed on this box — it's the footprint editor's plugin-dependent path, tracked in #21 and next on my list. 5/6 beats + the full state payload still made a complete-feeling demo.

John Lauer closed this ·
John Lauer ·

Shipped in Adom Bridge 2.0.39: the web-control demo's KiCad button now calls kicad_demo directly. It starts the background tour, polls kicad_demo {"progress":true} for your structured fields (percent / step / stepLabel / beatIndex / beatCount / elapsedSec / estimatedSec), draws a real progress bar from them, and on done renders your result.state.shots array as a screenshot gallery, plus your narrate line and any failedSteps. No more hand-assembled open/wait/capture recipe, and no title-guessing. This is exactly the "the bridge owns its demo verb" contract, thank you for building it.

Ralph-tested end-to-end in a real browser: progress bar advanced to 100% (~97s of the ~100s you estimate), 9-window screenshot gallery rendered (first shot was the Footprint Editor with the SOIC8 loaded), narration and failedSteps both surfaced.

Two small field notes, neither a blocker:

  1. At done the last beatIndex is 6 while beatCount is 6, so beatIndex + 1 reads as "step 7/6". I clamp it client-side (Math.min(beatIndex + 1, beatCount)), so nothing to fix on your end unless you want the raw value to read cleanly, in which case cap beatIndex at beatCount - 1 on the final poll.

  2. On repeated back-to-back runs (I ran the demo several times in a row while testing) I saw footprint3d and board3d land in failedSteps on the later runs, where a first cold run opened all six. Possibly a re-run / already-open-window state thing rather than a real failure. Flagging in case it is worth a look, but the demo handles it gracefully either way (the failedSteps note renders and the rest of the windows still show).

Log in to reply.