370 downloads in the last 30 days
2026-09-07: 6 downloads2026-09-08: 5 downloads2026-09-09: 6 downloads2026-09-10: 1 download2026-09-11: 5 downloads2026-09-12: 7 downloads2026-09-13: 5 downloads2026-09-14: 8 downloads2026-09-15: 1 download2026-09-16: 3 downloads2026-09-17: 3 downloads2026-09-18: 22 downloads2026-09-19: 3 downloads2026-09-20: 11 downloads2026-09-21: 19 downloads2026-09-22: 5 downloads2026-09-23: 25 downloads2026-09-24: 0 downloads2026-09-25: 5 downloads2026-09-26: 3 downloads2026-09-27: 1 download2026-09-28: 0 downloads2026-09-29: 9 downloads2026-09-30: 6 downloads2026-10-01: 16 downloads2026-10-02: 19 downloads2026-10-03: 10 downloads2026-10-04: 10 downloads2026-10-05: 26 downloads2026-10-06: 130 downloads

Releases 350

Standalone per-platform binaries to download and run, no tools needed. The newest is pinned on top.

Compare →
Latest release v1.0.55

Stable link for websites and docs: /download/adom/kicad-bridge/latest

All releases showing 201-220 of 350

v0.9.191 2026-08-19

Adopts the canonical background/foreground RESPONSE contract from SDK issue #38. Where a window went is now the enum windowEtiquette (background | foreground) rather than the boolean openedInBackground, and a bare foreground:true is refused with errorCode foreground_reason_required rather than the underscore-prefixed _foregroundRefused. Both old keys are still emitted during the migration window so a pinned runner does not break. The reasoning is right and generalizes: what a caller has to BRANCH on is a contract and deserves a stable non-underscore key, and a boolean cannot grow when the states are already three. focusEvents keeps its name, blessed as-is.

v0.9.190 2026-08-19

The real cause of wiki issue #34, found by the new kicad_plugin_diagnose verb, and it was mine rather than anything about the reporter's KiCad. While removing an accidental duplicate import in plugin_install.py, a blanket edit stripped EVERY line reading import sys from that file - including the one inside the generated loader's source TEXT. So from that point on, every fresh plugin deploy wrote an adom_bridge_plugin.py that raised NameError: name 'sys' is not defined the instant KiCad imported it. It failed silently because the loader catches its own exceptions into a log file, so KiCad saw a plugin that did nothing and the bridge saw no live instance - which looked exactly like 'this KiCad does not scan its plugin directory'. It scans it fine; the file we put there was broken. Restored, and the class of break is closed: plugin_install now EXECUTES both generated loaders in a throwaway namespace at import time and raises loudly if either fails or logs an error, because generated code is shipped as text and is otherwise never run on this side.

v0.9.189 2026-08-19

Adds kicad_plugin_diagnose, a read-only verb that answers 'why is the reverse-bridge plugin not loading' in one call instead of several rounds of file requests. It reports whether the loader is deployed, whether KiCad actually IMPORTED it (a pycache entry beside it is the proof), what the loader logged, which KiCad executables ever ran the bootstrap, whether KiCad's embedded stdlib is complete (a real machine turned out to be missing Lib/urllib entirely, which made every import of the payload fail and which no bridge code can work around), and the live instances - then states a plain verdict: WORKING, NOT DEPLOYED, DEPLOYED BUT NEVER IMPORTED, or IMPORTED BUT DID NOT START. Written for wiki issue #34, where the plugin binds on two of this maintainer's boxes and not on the reporter's, and the distinguishing evidence all lives on his machine.