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

Plugin no longer binds in eeschema/pcbnew (only kicad.exe) — breaks background canvas-load tier

John Lauer · ·closed by John Lauer

Finding from the new daily verb suite (runs #2/#3, 2026-08-14): the in-process plugin no longer loads in eeschema/pcbnew on AdomLapper — only kicad.exe (project manager) binds it.

Evidence:

  • Every fresh discovery file in %TEMP% is adom-kicad-bridge-kicad-<pid>.json; zero eeschema-/pcbnew- files despite editors opening and working.
  • kicad_bridge_status: payload deployed + sha-current (0.9.1) at the KiCad 10.0 USER_SITE, but 0 alive editor instances.
  • Editors spawned via the project manager's menus (the open_* verbs' WM_COMMAND tier): no plugin.
  • Even a DIRECTLY launched eeschema.exe (which is how it worked on 2026-08-09, verified then with a live background canvas-load) does not bind the plugin today — waited 20s+, no discovery file for its PID.

Impact: open_symbol_editor's plugin-first background canvas load falls back to the PS path (flaky), so the #20 acceptance test (Device:R verified load) fails in the daily suite. open_footprint_editor's WM_COMMAND tier is also plugin-dependent and failing.

Hypotheses to run down (in order):

  1. KiCad 10.0.x patch on the box changed when eeschema initializes its embedded Python (usercustomize only runs at interpreter init; kicad.exe still inits, editors no longer do until scripting is touched).
  2. The sitecustomize USER_SITE path (Documents/KiCad/10.0/3rdparty/Python311/site-packages) may no longer be on eeschema's sys.path in the current build (Python311 hardcode vs a bumped embedded Python?).
  3. Something environmental on this box (the 08-09 success was real and repeated).

Next diagnostic: dump sys.path + python version from INSIDE a PM-spawned vs directly-spawned eeschema (scripting console or a kipy probe), and check the KiCad build number then vs now (Windows update logs / installer history).

The daily suite tracks this as the 2 remaining GUI failures; everything else is green (44/47 + justified skip).

3 Replies

John Lauer ·

Diagnosis correction after deeper on-box work (same day):

The plugin DOES still bind in eeschema — just LATE. My probe eeschema (PID 37544) wrote its discovery file well after the 22s window I'd watched; the earlier "even direct launch doesn't bind" claim was a too-short observation window, retracted. KiCad's bundled Python is still 3.11.5 (Python311 USER_SITE path is correct) and the payload files are deployed + sha-current.

Where that leaves the bug: the editors initialize their embedded Python MINUTES after process start (kicad.exe PM does it quickly), and adom_bridge.start() itself binds in ~0.1s once usercustomize fires — so the whole latency is KiCad's interpreter-init timing, not ours. Verbs that wait 12s for the plugin can't bridge a minutes-scale gap.

Open questions (the actual remaining work):

  1. What triggers eeschema/pcbnew python init in KiCad 10.0 — and can a verb poke it cheaply (kipy/IPC ping? opening a scripting-adjacent feature)? If yes, open_symbol_editor can trigger-then-wait instead of hope.
  2. Why the Aug-9 sessions bound fast enough for the live canvas-load demo — document-at-launch vs bare editor is the leading variable.
  3. Fallback hardening: the PS navigate path is the safety net meanwhile; the verb's honest symbolLoaded:false (0.9.77) keeps failures visible in the daily suite (baselined until this closes).
John Lauer ·

Update: #20 is no longer blocked on this — 0.9.85/0.9.86 added a plugin-free win32 background tier (filter + Down through the search box, Enter/dblclick to the tree) that loads symbols while the editor's Python is still cold. This issue stays open for the plugin-bind latency itself (the in-process canvas-load path is still preferable when alive, and the footprint editor's WM_COMMAND tier still depends on it), but it's now an optimization, not a user-facing breakage.

John Lauer ·

Closing — the user-visible breakage this issue tracked is gone, via an architecture change rather than fixing the bind latency itself:

  • Symbol editor (0.9.86) and footprint editor (0.9.89-0.9.91) both load their requested part from FULLY CLOSED via a plugin-free win32 background tier (WM_SETTEXT filter → Down through the search box → Enter/dblclick to the tree, title-verified, zero focus theft). Verified live cold: Device:R, Device:C, Resistor_SMD:R_0603_1608Metric all load.
  • The fp cold path also needed two open-phase fixes this issue's investigation surfaced: the PM-menu plugin tier now RETRIES after the project manager launches (0.9.90 — it previously only ran before anything existed), and the window wait covers the spawned pcbnew loading 100+ footprint libraries (0.9.91 — slower now that 0.9.84 restored the stock libs).
  • The daily verb suite baseline is now EMPTY — all 48 verbs expected green.

What remains true (documented in the kicad-bridge-dev skill for future work): KiCad 10 editors initialize their embedded Python minutes after launch, kicad.exe binds within seconds, and the in-process canvas-load RPC is therefore an optimization we don't currently depend on. If a future feature needs fast in-editor Python, start from the diagnostics in this thread (the init trigger hunt), and reopen.

John Lauer closed this ·

Log in to reply.