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 general

kicad_open_editors doesn't cold-launch KiCad (no launch verb)

John Lauer · ·closed by John Lauer

Finding: kicad_open_editors is a no-op when KiCad is closed, and there is no cold-launch verb.

Reproduced live on a box with KiCad 9.0 + 10.0 installed, KiCad fully closed:

  • kicad_open_editors -> returns success:true but launches nothing: 0 windows appear, no kicad.exe in the process list, and desktop_wait_for_window {titleContains:"KiCad"} times out. The response hint explains it: it opens editor frames inside an already-running KiCad via the plugin, so with nothing running it has nothing to open into.
  • kicad_open_symbol_editor (same closed state) -> success:true AND cold-launches KiCad: kicad.exe appears and both the KiCad 10.0 project manager window and a Symbol Editor window come up.

So the two "open" verbs disagree on cold-start behavior, and the one whose name reads like "open KiCad" (kicad_open_editors) is the one that does NOT launch it.

Ask (either is fine):

  1. Make kicad_open_editors cold-launch KiCad when no instance is running (then open the editors), or
  2. Add a first-class kicad_launch (the KiCad analogue of fusion_start) that cold-starts the project manager.

Context: found while testing Adom Bridge's new web-control feature -- a web page fired kicad_open_editors expecting KiCad to open, and it silently did nothing. Not an ab-core bug (ab relays the verb verbatim); it's the bridge's cold-start contract. No rush, just flagging so "open KiCad from closed" works for the common case.

2 Replies

John Lauer ·

Shipped in runtime v0.9.76 — went with option 2 plus a teaching fix for the trap you hit:

New verb kicad_launch — the KiCad analogue of fusion_start:

  • Cold-starts the project manager via the detected kicad.exe, in the BACKGROUND (no-activate startupinfo, per the bridge's focus rules), then polls up to waitSeconds (default 15) for a KiCad window and returns the titles.
  • Idempotent: if KiCad is already up it's a no-op that returns the live window list.
  • Optional project: absolute path to a .kicad_pro to open with it.
  • No KiCad installed → clean error routing to kicad_readiness / kicad_upgrade.

Why not option 1: kicad_open_editors is (despite its name) a read-only INVENTORY verb — it lists editor frames via the in-process plugins. Making a lister launch things felt worse than giving launch its own verb. Instead the trap is now closed at the response level: with 0 editors AND 0 live plugins, open_editors returns kicadRunning:false and a _hint that says exactly "this verb never launches — use kicad_launch", and its describe entry says the same. A web page (or AI) that fires it against a closed KiCad now gets told what to call instead of a silent empty success.

Live-box verification is pending the next healthy respawn window on AdomLapper (adom-bridge#56 still flapping there); the verb is in the served 0.9.76 manifest (sha cb2d1a13...).

John Lauer ·

Closing: kicad_launch shipped in 0.9.76 and PASSES in the daily verb suite (runs 2/3, cold-start and idempotent paths both). open_editors teaches the distinction in its zero-editor hint + describe entry.

John Lauer closed this ·

Log in to reply.