2 Commits

Include renames

Author	SHA1	Message	Date
Tommaso BianchiandClaude Opus 5	e5659e0f0f	The value field stops being a window, and now takes what is typed ... Rebases the in-canvas work onto cad-mainline and finishes it. The field is drawn by ImGui inside the GL canvas instead of being a borderless top-level wxFrame. WHY THE FLOATING FRAME COULD NOT BE FIXED. Whether a borderless top-level may hold the keyboard is the window manager's decision, and it differs per desktop: openbox grants it, mutter refuses it, macOS denies key status outright. Seven workarounds fought that and one cost a macOS regression. Drawn inside the canvas there is no second top-level for anyone to refuse, so the question is never asked. The field is fed exactly like every other ImGui widget in the app — GLCanvas3D::on_char -> ImGuiWrapper::update_key_data -> io.AddInputCharacter. MEASURED, on behemoth: the click-edit ladder holds 28 checks — Line, Rectangle, Circle, Slot, Polygon, Ellipse, Arc, and click-to-edit on a placed dimension label — typing with NO click into the field first, committed == typed != prefill every time, and 27 [UX] imgui_char lines showing the characters arriving. WHAT WAS ACTUALLY WRONG. Not the field. The belief that "characters never reach the ImGui InputText" came from the harness: the ladder was delivering keys with `xdotool type --window` (XSendEvent), which GTK discards, so no build of any kind could have received them. The new probe in ImGuiWrapper::update_key_data — the one place ImGui is ever handed a character — is what separated that from a real defect, and it stays, because a canvas-side probe provably cannot answer the question: GLCanvas3D::on_char is bound later than any constructor-time probe, wx runs handlers in reverse bind order, and on_char returns without Skip(), so such a probe is silent whether or not the key arrived. A day was lost reading that silence as evidence. Also drops DesignPanel's content-based forwarder and DesignCanvas::inline_type_char. They were the right rule for a field that could not be focused; with the field inside the canvas there is nothing to forward, and keeping them would have masked whether the normal path works. STILL UNVERIFIED: behaviour under mutter itself. Neither focus-stealing-prevention WM available here survives long enough to judge — metacity SEGVs ~20s in and xfwm4 dies with BadWindow on SetInputFocus, both before the sketch opens and both unrelated to this field. The design's claim is structural rather than measured: no second top-level means no focus to refuse. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA	2026-09-06 11:10:02 +02:00
Tommaso BianchiandClaude Opus 5	9134299233	Sketch value fields: content-based key arbiter + the gate that can judge it ... The reported defect: sketch dimension labels are "not editable" — you draw a rectangle, its Width field opens, you type, and the as-drawn number is committed instead. It affects every sketch tool, not just the rounded rectangle. WHAT THIS ADDS 1. The arbiter (DesignPanel CHAR_HOOK -> DesignCanvas::inline_type_char -> SketchInlineEditor::type_char). Routes a key by what it IS, not by who the window manager focused: digits, sign, decimal separator and Backspace/Delete go to the open value field, Enter/Tab commit, letters stay tool shortcuts. This is FreeCAD Sketcher's rule (DrawSketchKeyboardManager:: detectKeyboardEventHandlingMode), and the reason its sketcher behaves the same on every desktop: it never asks who has focus. 2. The [UX] trace (SNAPORCA_UXTRACE) in SketchInlineEditor: open/commit/refused/ cancel, with the prefill and what the control actually held at Enter. It did not exist — the ladder below was written against a surface no build emitted, so it could only ever report "nothing opened". typed == prefill on a commit is the defect's signature and nothing else makes it visible. 3. A draw-then-edit trace in DesignSketchTool: four early returns can swallow the value-field chain and from outside they are indistinguishable. 4. scripts/CAD/check-gui-click-edit.py — types WITHOUT clicking the field, as a person does, across Line/Rectangle/Circle/Slot/Polygon/Ellipse/Arc plus label click-to-edit, and asserts committed == typed != prefill. 5. scripts/CAD/focus-loop.sh — sync/build/assert on behemoth. NOT the orcacad-gui rig: its image pins deps 216 non-CAD files behind cad-mainline, so today's CAD sources cannot build there without a deps rebuild. WHAT IS PROVEN, AND WHAT IS NOT Green under openbox: 28 checks, every tool, committed == typed != prefill. But openbox CANNOT adjudicate this bug and the ladder says so in place. There the field always wins the keyboard, so the same ladder also passes against a binary with the arbiter compiled out — measured twice. Two ways of removing the keyboard were tried and both are recorded as dead ends: XSetInputFocus loses to the field's own re-focus CallAfter, and XSendEvent (xdotool --window) is dropped by GTK, which made every run red regardless of the code. Under metacity — same focus-stealing-prevention lineage as the user's mutter — the mechanism appears in the WM's own log: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 That is the activation being refused, which is exactly the reported symptom. present_toplevel() already asks for a server timestamp, so a path is still falling through to frame->Raise(), which sends time 0. That is the next thing to fix, and it is tracked; the arbiter alone does not close it. metacity also aborts on this window (frames.c:1239), so the gate needs a WM that survives before it can return a verdict. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA	2026-09-06 10:35:22 +02:00