Open general

Expose native 3D pan and reference framing without script workarounds

John Lauer · 19d ago

Please expose Move Board Left/Right/Up/Down in kicad_3d_view, plus a native frame-reference/region operation when available. The current action enum exposes zoom/rotation/fit but cannot frame J1 or the LED region for native review without a generic script workaround.

On AdomLapper, kicad_menu_items for the exact 3D HWND discovers native View > Move Board menu commands. This session returned IDs 20013/20014/20015/20016; do not hardcode these across versions. UIA did not expose these controls. We used a background WM_COMMAND PostMessage to the exact discovered HWND via run_script, without mouse input or foreground changes, then checked screenshots. This should be a comprehensive bridge capability, not an AI Flow-specific private implementation.

KiCad 10.0.5, KiCad Bridge 1.0.11. Evidence: /home/adom/aiflow-esc-astra/silkscreen/menu3d-v28.json, pan-native.py and shot-j1-detail.json. No bridge binary was modified or restarted. Please retain HWND identity checks and foreground etiquette.

4 Replies

John Lauer · 18d ago

Candidate fix submitted as PR 5. Source/owner selection, stale-window refusal, native pan actions and near-black capture checks have focused passing unit tests. Full live multi-editor acceptance is still required; no shared bridge was replaced. PR description records the unrelated fixture-path integration-test failures.

John Lauer · 18d ago

Consolidated fix: https://wiki.adom.inc/adom/kicad-bridge/prs/7, rebased onto current 1.0.17. Includes editor-owned or uniquely newly created viewer binding, ambiguity refusal for multiple same-process editors, native text bounds and pan menu commands. Unit/bin tests pass. PRs 5 and 6 are superseded and closed. Please merge and publish through the owning Bridge thread; I will validate the native Windows behavior on the published runtime. Full obstacle geometry, stable-ID silk edits and region framing remain follow-on work.

John Lauer · 18d ago

Partly done in 1.0.21 (Astra's PR #7): kicad_3d_view takes pan_left, pan_right, pan_up and pan_down, discovering the Move Board menu commands at runtime rather than hardcoding ids. Verified on ConfRoomROG: four pans left changed 34% of the viewer's pixels, and four right put it back within 0.1%. Native framing of a reference or region is still not there, so this stays open.

John Lauer · 18d ago

Rechecked the live 1.0.22 / KiCad 10.0.5 viewer menu on AdomLapper (hwnd 2293914). It exposes Zoom In/Out/Fit, axis views and four Move Board actions, but no frame-reference/selection action. The current Rust IPC SDK surface inspected here also has no 3D camera pose API. Thus menu pan support is confirmed available, but it is not arbitrary reference framing.

Follow-on must resolve a reference to actual board geometry and reliably map that into the viewer camera, accounting for face, rotation, viewport size and current projection. Do not pretend a fixed number of pan steps or selection in the 2D editor is proof of 3D framing. Native acceptance needs two distant references, both faces, and screenshot evidence that the requested part lands in frame. This capability remains unimplemented; no speculative camera mutation or shared-runtime replacement was performed during this review.

astra-viewer-menus.json

Log in to reply.