jpmschweitzer/settled-reach
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(decisions): D-169 Implant UI component library — Control node tree

Browse Source 
Control nodes with shared Theme resource, not _draw() components.
Dynamic implant system (hardware variants, upgrades, faction overlays)
requires layout automation and theme swapping that _draw() can't provide.

Component set: Panel, Header, Separator, DataRow, TextBlock, StatusBadge,
ProgressBar, TabRow, Expandable. Semantic color roles defined.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
jpmschweitzer
2026-04-05 10:43:05 +02:00
co-authored by Claude Opus 4.6
parent 8d02b110ae
commit 4dd95ba50b
1 changed files with 24 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
decisions/architecture.md
+24
View File
@@ -598,4 +598,28 @@ Technical foundation decisions that constrain implementation: engine, client-ser
---
### D-169: Implant UI component library — Control node tree with custom Theme
- **Date:** 2026-04-05
- **Decision:** The implant UI (all diegetic neural overlay panels — star map info, travel planner, station profiles, GTTR reader, cargo manifest, etc.) uses **Godot Control node components** composed in scenes, styled via a shared `Theme` resource. Not `_draw()` draw-objects, not hand-rolled rendering.
- **Rationale:** The implant system is tagged as dynamic — different hardware, upgrades, damage states, and faction overlays will change the UI's look and behavior at runtime. This requires layout automation (reflow, resize, expand/collapse), accessibility support, and theme swapping — all things Godot's Control tree provides and a `_draw()` approach would need to reimplement. The team (Tyre, Stig, Araminta) initially favored `_draw()` for pixel control, but the dynamic implant requirement makes Control nodes the better long-term investment.
- **Architecture:**
- `ImplantPanel` — `PanelContainer` with theme override, serves as root for any implant overlay
- `ImplantHeader` — `HBoxContainer` (title label + subtitle label)
- `ImplantSeparator` — `HSeparator` with theme override
- `ImplantDataRow` — `HBoxContainer` (key label + value label, two-column)
- `ImplantTextBlock` — `RichTextLabel` for wrapping narrative text
- `ImplantStatusBadge` — colored dot + label
- `ImplantProgressBar` — two-tone, no gradients
- `ImplantTabRow` — uppercase labels, underline-active pattern
- `ImplantExpandable` — chevron + collapsible section
- Theme resource (`.tres`) defines: colors (primary, dim, accent active/positive/negative/warning), spacing (line height, separator padding, panel padding), font sizes (header, body, small, caption)
- Different implant hardware swaps the entire Theme resource at runtime
- **Rejected alternative:** R-NNN `_draw()` RefCounted components — pixel-precise, zero scene tree overhead, but would require reimplementing layout automation, scroll, and interaction handling as the implant system grows. Correct for a static HUD; wrong for a dynamic system.
- **Raised by:** Jeroen + Tyre/Stig/Araminta design discussion, 2026-04-05
- **Dissent:** Tyre and Stig initially favored `_draw()` for aesthetic control. Reversed when the dynamic implant requirement was surfaced.
- **Semantic color roles:** `PRIMARY_TEXT` (#c8d0e0), `DIM_TEXT` (#667788), `ACCENT_ACTIVE` (#f0d060), `ACCENT_POSITIVE` (#44aa66), `ACCENT_NEGATIVE` (#aa4444), `ACCENT_WARNING` (#aa8844), `SEPARATOR` (#c8d0e0 at 12%)
- **Interaction pattern:** Invisible until touched. Hover shows 0.3 alpha rect. Active shifts text to `ACCENT_ACTIVE`. No button chrome — the implant doesn't label its affordances.
---
*50 decisions. Last updated: 2026-03-24 (D-101 partial supersession noted; D-166 development cascade added)*