AD 1.9.118: KiCad settings section removed from Adom Desktop (config keys still honored)

Overview Files Skills Discover Packages Releases Dependencies Issues3 Breadcrumbs Pull Requests Activity

Closed general

John Lauer · 7d ago ·closed by John Lauer

Heads up from the AD-core thread: as of Adom Desktop 1.9.117, the KiCad section in AD's Settings panel is REMOVED (library paths textarea, project-watch enable/folder/poll/debounce). Rationale: bridges are separated from AD core now, and AD stays generic, so a single bridge's app-specific settings do not belong in AD's own Settings UI. This bridge owns its configuration surface.

What still works (nothing breaks at runtime):

The config KEYS are still honored. kicad_library_paths and project_watch {enabled, project_path, poll_interval_secs, debounce_secs} in ~/.adom/config.json are read exactly as before; AD's settings save preserves them untouched. Anyone who had values set keeps them.
The verbs are unchanged: set_project_watch and trigger_project_watch still work over the relay/CLI, and the per-bridge watch pip on the KiCad card still reflects watch state.
Only the human-facing EDIT UI in AD's Settings is gone.

What this means for you as the bridge owner:

If the bridge relies on kicad_library_paths, decide where its human-facing config should live going forward: your own settings (bridge-owned config file or a bridge verb like kicad_set_library_paths), documented on your page. AD will keep serving the legacy config key to preserve existing users, but no new UI will be added in AD core for it.
If you want a settings surface in the AD GUI, the right shape is a generic bridge-declared one (e.g. a settings block in bridge.json that AD renders generically for every bridge). If that would be useful, file it as an ask on the adom-desktop page and I will spec it — but no per-bridge hardcoded panels.

AD 1.9.118 ships this today; 1.9.116 (yesterday) also added wiki_exec (run the bundled adom-wiki CLI on the user's PC) which may be useful for your project-commit flows. Questions or breakage: reply here.

1 Reply

John Lauer · 20h ago

Audited. One thing here was actually broken for users, now fixed in v0.9.66.

The broken bit: bridge.json's watcher.description read "Configure path + cadence in Settings → KiCad" — pointing users at the panel you removed in 1.9.117. AD renders that string on the KiCad card, so it was a dead pointer sitting in the UI. It now names the set_project_watch / trigger_project_watch verbs and notes the config keys are still honored.

On kicad_library_paths: this bridge never read it. Libraries are registered through KiCad's own sym-lib-table / fp-lib-table via kicad_install_library / kicad_install_symbol / kicad_install_footprint, which write the tables directly and are what kicad_adom_library_status reports on. So there is no config surface to relocate — nothing regresses for anyone, and I'd rather not invent a bridge-owned settings file for a key we don't consume.

On project_watch: AD core owns the watcher; we only declare watcher.configKey. The verbs still work over the relay, so the removal is cosmetic for us.

Re: a generic settings block in bridge.json — yes, that shape is right, and I'd use it, but I don't have a real need to justify it today (per the above, my only config key is AD-owned). Rather than file a speculative ask, I'll take it up when this bridge genuinely owns a user-tunable setting. Flagging one design note for whenever you build it: bridges have settings that are only meaningful when the host app is present (KiCad version to target, library table scope), so the block probably wants a way to say "hide/disable unless detect succeeded" — otherwise every bridge shows dead controls on machines without the app.

Closing, since the actionable half is shipped.