From 83076cdbb693dce443541bbce4a73238dcaeb113 Mon Sep 17 00:00:00 2001 From: Erik Date: Tue, 16 Jun 2026 17:54:52 +0200 Subject: [PATCH] =?UTF-8?q?docs(D.2b):=20spec=20correction=20=E2=80=94=20i?= =?UTF-8?q?nput=20is=20Variant=20B,=20Type=203=20not=20registered?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Record the two execution-time corrections to the design's registration assumptions: the editable input resolves to Type 12 (Variant B, controller-placed UiField), and Type 3 is NOT factory-registered (acdream's Type-3 elements are chrome/containers, kept on the UiDatElement fallback). Co-Authored-By: Claude Opus 4.8 (1M context) --- ...-06-16-d2b-widget-generalization-design.md | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/docs/superpowers/specs/2026-06-16-d2b-widget-generalization-design.md b/docs/superpowers/specs/2026-06-16-d2b-widget-generalization-design.md index 12dcd6c5..8c61043b 100644 --- a/docs/superpowers/specs/2026-06-16-d2b-widget-generalization-design.md +++ b/docs/superpowers/specs/2026-06-16-d2b-widget-generalization-design.md @@ -108,6 +108,30 @@ Type 0 has no class of its own — a Type-0 element is a placement/override that inherits its class from its base. That is exactly what `ElementReader.Merge` already does. +> **Implementation correction (2026-06-16, settled during execution).** Two of +> this design's registration assumptions changed once the empirical resolved +> Types were in hand (Task 1): +> 1. **The editable input `0x10000016` resolves to Type 12 (Text), not Type 3.** +> So the input is **Variant B** — the factory builds it as a `UiText` +> placeholder and `ChatWindowController` removes that and controller-places a +> `UiField` at its rect. (Confirmed by the chat golden fixture.) +> 2. **Type 3 is NOT registered → `UiField` in this pass.** In acdream's vitals +> (`0x2100006C`) and chat (`0x21000006`) layouts, Type-3 dat elements are +> sprite-bearing **chrome** (the 8-piece bevel corners/edges, e.g. vitals +> `0x10000633` → sprite `0x060074C3`) and the transcript/input **container** +> panels — NOT editable fields. Retail draws those as inert media-bearing +> Fields, which our generic `UiDatElement` reproduces pixel-for-pixel and +> without a spurious focus/edit affordance. Registering Type 3 → `UiField` +> (which draws no dat sprite) would blank the vitals bevel. So the factory +> switch registers **Button (1), Menu (6), Meter (7), Scrollbar (11), Text +> (12)**; Type 3 stays on the `UiDatElement` fallback. `UiField` still ships +> (the renamed editable widget) — it is just controller-placed, not +> factory-wired. Register Type 3 → `UiField` only when a window carries a +> factory-built editable Type-3 field (and `UiField` then grows a +> background-media draw + an opt-in editable flag). Guarded by +> `VitalsTree_ChromeCornerHasExpectedSprite` (asserts the corner stays a +> `UiDatElement` drawing its sprite). + ### 2.2 The `gm*UI::PostInit` binding pattern (the controller target) `gmVitalsUI::PostInit` (`acclient_2013_pseudo_c.txt:199170-199228`) and