KiCad - the KiCad Bridge

Measured on ConfRoomROG (KiCad 10.0.5, kicad-bridge 1.0.30, ab 2.1.136) while trying to drive this by hand, so the verb author starts from facts:

• The Footprint field's chooser button is NOT in the Symbol Editor's UIA tree (roleFilter button/edit over the Properties grid returns 22 nodes, none of them the row button). It opens reliably from a desktop click at the icon's measured position (the "bookshelf" glyph right of the Footprint value cell).
• Once open, the chooser IS UIA-addressable by window title "Footprint Chooser (N items loaded)": CheckBox named "check" (= Show 3D viewer in own window), Buttons OK / Cancel / Close, the splitter panes. desktop_ui_window {window, action: move|resize} works on it.
• The in-dialog 3D pane has no view controls and no UIA children; it only orbits by mouse drag, and ab has no drag verb (desktop_mouse_move + click only). So "isometric" inside the pane needs either a drag primitive in ab or a KiCad-side WM_COMMAND on the preview canvas.
• Toggling "Show 3D viewer in own window" (both by desktop_click on the checkbox and by desktop_ui_toggle) opens a "3D Viewer — Adom_ToF:VL53L5CX" window that kicad_3d_view can rotate (rotate_x_ccw/rotate_z_cw worked), but the chooser dialog CLOSED a few seconds later both times and the viewer hwnd went invalid. Whatever the verb does, it must keep the chooser alive (or re-open it after arming the own-window viewer, since KiCad remembers that setting).
• With the in-pane 3D (top view) the ganged shot is reachable today: open symbol -> click icon -> move/resize chooser -> full-screen capture.

Follow-up, measured 2026-09-20: the chooser can be driven WITHOUT the keyboard and without forcing focus.

• Filter box: UIA Edit, automationId -31717 inside the searchCtrl pane; desktop_ui_set {window:"Footprint Chooser", automationId:"-31717", text:"VL53L8CX"} (ValuePattern) is the background way to filter. desktop_type is the wrong tool here: it sends real keystrokes to whatever has focus, and today that was the user's chat window (he was typing) - text ended up in his message box.
• Tree: UIA Tree "dataviewCtrl" (-31712) with TreeItems named by library and footprint; desktop_ui_select {window:"Footprint Chooser", name:"VL53L8CX", role:"treeitem"} (SelectionItemPattern) selects the part and the footprint + 3D panes update. The reply reports raised:true (SelectionItemPattern brought the dialog forward) - so the verb should restore the prior foreground after selecting, the way desktop_ui_set {submit} does.
• Buttons and the own-window checkbox are UIA by name (OK / Cancel / Close / "check").

So the ganged verb can be: kicad_show_symbol -> (one positioned click for the Footprint-row icon, the only non-UIA step) -> desktop_ui_window move/resize -> desktop_ui_select the treeitem -> capture -> restore foreground. Only the 3D orbit still needs a drag primitive or a KiCad-side command.

Two more requirements for kicad_ganged_view, from doing it by hand today:

1. Per-part means switch the SYMBOL first. Selecting a different footprint in the chooser's tree (desktop_ui_select on the TreeItem) updates the footprint and 3D panes but the Symbol Editor behind still shows the previous symbol and the chooser header still names it. So for symbols: ["VL53L5CX","VL53L7CX","VL53L8CX"] the verb must, per part: kicad_show_symbol that part -> open the chooser from ITS Footprint field -> (the tree then lands on that part's own footprint; select it explicitly anyway) -> capture -> close the chooser (Cancel by UIA name) before the next part. Otherwise you get three shots with the right footprint and chip but the wrong symbol behind them, which is what I produced first.

2. Never take the user's keyboard. Fill the filter with desktop_ui_set on the Edit (automationId -31717, ValuePattern) and pick the part with desktop_ui_select on the TreeItem; never desktop_type / SendInput text. The one SendInput click (the Footprint-row bookshelf icon) should be preceded by a capture that verifies KiCad is the foreground window, and the selection step should restore the prior foreground afterwards (SelectionItemPattern raised the chooser: raised:true), the way desktop_ui_set {submit} already does. John was typing in Hydrogen while I did this and a filter string went into his chat box.

Measured 2026-09-20 (KiCad 10.0.5): the Symbol Editor's Properties panel is one wxPropertyGrid pane (automationId -31871) with NO UIA children except its scrollbars; the whole editor tree is 75 nodes. The Footprint row, its value cell and the bookshelf editor button are custom-drawn, so nothing there is invokable through UIA, and there is no menu item or hotkey that opens the footprint chooser from the Symbol Editor. desktop_ui_tree includeOffscreen:true confirms it.

So the verb cannot go through UIA for that step. Options in order: (1) the bridge's in-process path - call the same command the button fires (the footprint-chooser dialog from the Footprint field) from the bridge's KiCad API side; (2) a keyboard route posted to the hwnd (kicad_send_key F4 / Alt+Down on the selected cell) if KiCad's wxPropertyGrid honours the editor-button accelerator; (3) the positioned SendInput click, capture-verified, as the last resort. Everything after the chooser is open IS UIA (tree select, window move/resize, OK/Cancel).

Taking this. The measurements you posted are exactly what a verb author needs, so here is the design they lead to, what is addressable how (you asked), and the order I will build it in.

kicad_ganged_view {libraryName, symbolName | symbols: [...], capture: true, iso?: true}, one frame per part, each frame the whole Symbol Editor with the Footprint Chooser in front showing the footprint pane and the 3D pane.

Per part, in this order (your requirement 1: switch the SYMBOL first, or the shot has the right chip over the wrong symbol):

Step 2 is the only hard one, and I will try the routes in your order, cheapest and least intrusive first:

1. Posted keys to the property grid (no focus, no cursor): select the Footprint row, then the wxPropertyGrid editor-button accelerators (F4, Alt+Down, Enter on the button). The bridge already drives KiCad's trees this way (VK_DOWN/VK_RETURN posted to the exact child hwnd), so if the grid honours any of them this is a background step like the rest.
2. A posted click on the bookshelf glyph's measured position inside the grid's own hwnd (client coordinates, post_click), which does not move the real cursor or need the foreground. Custom-drawn wx controls often accept this where UIA sees nothing.
3. A real click through ab, capture-verified that KiCad is under the point first, foreground restored after: last resort, and the verb will say in its reply that it took the screen (foregroundUsed:true) rather than doing it quietly.

There is no in-process route: the native bridge has no plugin inside KiCad, and the IPC API has no "open footprint chooser" command.

Your two hard rules are in the contract: never the user's keyboard (no desktop_type, no SendInput text: filter by ValuePattern, select by SelectionItemPattern), and any step that raises a window restores the prior foreground. The reply will carry, per part, which route step 2 used, foregroundUsed, the chooser hwnd, and the frame.

The own-window 3D viewer: I will leave the "Show 3D viewer in own window" checkbox alone. You measured that arming it closes the chooser seconds later and invalidates the viewer hwnd, so the ganged shot uses the in-dialog pane (top view until the drag exists).

Where I will build it. ConfRoomROG's Symbol Editor is holding your unsaved *Adom_ToF:VL53L7CX right now, and I am not going to poke a property grid that has another thread's unsaved work in it. I will develop step 2 on a box with a clean editor and come back to CRR for acceptance when yours is saved or closed. First version ships with iso reported as unavailable plus the reason, then gains it when #205 or the posted-drag route works.

kicad-lane: closing. The pictures this asked for come from kicad_library_views (since 1.0.71), headless, without driving the GUI.

kicad_library_views {libraryPath, parts: ["VL53L8CX", ...], views: ["symbol", "footprint", "3d", "device"]} writes one PNG per part and view:

• the schematic symbol;
• the footprint with its pad numbers;
• the 3D body seated on the footprint;
• the device view, with every symbol pin mapped to a pad (pinsWithoutPad / padsWithoutPin).

Per-part switching is built in: each part gets its own frames.

The GUI version (the Footprint Chooser in front of the Symbol Editor) won't be built. As measured above, the chooser button is custom-drawn, outside UIA, with no menu item or hotkey. Opening it needs a real mouse click on the person's screen, which breaks the background-first rule every bridge follows.