GuiProfileTheme: themes as the source of a Gui's look, and an editor for them

[greenfire27]

Themes become the way a Gui gets its look, and the Gui Editor gets a full editor for them.

Before this, a project's appearance came from ~70 hand-written GuiControlProfile objects in AppCore/scripts/guiProfiles.cs. Changing the accent colour meant editing dozens of them by hand and hoping you found them all, and a profile could only be edited through the raw inspector — every field, no context, no idea which ones the control you were skinning actually reads.

What this adds

GuiProfileTheme (engine/source/gui/guiProfileTheme.{h,cc}) — a set of theme-wide values (three fonts, six colours, a base font size, a base border size) and an engine-defined category table. On registration a theme creates one member profile per category, named <Theme><Suffix>, and stamps every field from a recipe. Change a theme value and every member restamps, skipping any field you explicitly overrode. Members serialise as ordinary TAML children, writing only their name, category and overrides. AppCore's script profiles are gone; GuiDefaultProfile moved into C++ so it exists before any script runs.

The Profile Editor — a full-screen dialog in the Gui Editor with a tree of themes, categories, borders and stand-alone profiles, and a purpose-built pane for each:

• a profile pane that shows only the fields the selected category actually renders, on a grid that reflows to the pane width, with per-field reset markers wherever you've diverged from the theme
• a borders pane and a shared 16-value border grid (margin/border/colour/padding × four states)
• a theme form for the six colours, three fonts and sizes
• a live preview of the category you're editing
• pickers rather than typing: installed fonts, image assets by thumbnail, bitmaps by file dialog

Set Theme re-profiles a whole Gui by control category in one action, and AppCore loads themes at runtime.

Highlights from the last few commits

• GuiColorPopupCtrl gains two optional rows (1bd02bb7): a swatch grid the Profile Editor fills with the selected theme's six colours, so setting a fill colour to the accent is a click rather than a hunt around the wheel; and an R/G/B/A row in 0–255 or 0.0–1.0. Both off by default, so existing popups are untouched.
• The colour pickers were quietly corrupting exact colours. Each one derives its colour by reading the pixel under its selector and pushing that back, which is right when you drag a selector and wrong when the popup placed it — a colour set from a swatch or typed into a box was overwritten by a framebuffer round-trip on the next frame, and simply opening a popup drifted the colour slightly. Fixed by suppressing one push-back when the popup is the one that moved the selector.
• A latent GuiControl tooltip bug (1bd02bb7): renderTooltip acquired a default tooltip profile without taking a reference while onSleep handed one back regardless, so any control with a tooltip and no tooltip profile slept one reference short. It only ever surfaced once something tooltipped lived somewhere that sleeps on a user action. Tooltips now also default to the Tooltip member of the theme the control's own profile belongs to, re-resolved per draw so a re-themed control's tips follow it.

Testing

tests/ (9338451d) collects the TorqueScript integration suites that drive the real engine — real canvas, real editor, real posted mouse and keyboard input. These are the only coverage the editors have; GoogleTest never reaches a canvas.

tests\run.ps1                 16 suites, exits non-zero on a change
tests\run.ps1 -Shots          7 screenshot harnesses

Current state — 16 of 16 suites clean, 448 checks, no failures and nothing killed: profileForm 83, assetPicker 64, standalone 60, themeApply 38, border 37, profileEditor 32, font 32, colorPopup 31, borderPane 20, planetX 18, headerPane 9, bitmapPathWrite 7, tooltipProfile 6, textClick 3, toybox 3, bitmapPathRead 1. The 7 shot harnesses write 20 screenshots.

tests/README.md documents the two engine facts that shape the setup: the boot script's own folder becomes the working directory, and a relative path is expanded against the calling script rather than the working directory.

Known issue

One, and it is not introduced here.

The profile-lifetime problem is still open. Assigning a profile through the Profile field on a live control bypasses the reference counting setControlProfile does, so a profile deleted while still worn leaves controls holding a dangling pointer. This PR adds mitigations at editor teardown, a "still worn" warning on ~GuiControlProfile, and — for tooltip profiles specifically — setControlTooltipProfile, which does the book-keeping properly. Closing it in general means routing the Profile and tooltipprofile persist fields through protected setters, which touches every control and every TAML load, so it wants its own pass rather than riding along here.

Correction

An earlier revision of this description, and the commit message in 9338451d, listed two failing suites as pre-existing engine problems — border losing nine checks and hanging on a teardown assert, profileForm losing one. Both claims were wrong, and 38adc8d6 and 88d225c2 fix them. Neither was an engine bug; both were stale tests asserting a design that had moved on.

border looked for a stand-alone profile's bundle with %profile.getGroup() and asserted it was a ScriptGroup. Bundles became SimSets deliberately — a group takes the profile out of GuiDataGroup, the only place the engine looks when filling a Profile dropdown — and a set leaves membership alone, so the test got GuiDataGroup back and then deleted it, destroying every editor profile. The fatal assert two lines later was the test asking for what it had just destroyed; shutdown was never reached. profileForm asserted a fontDirectory row was visible, but that field has no row at all: the editor owns it and points every profile at the project's one font folder, so isVisible() was being called on nothing.

Both now assert what the design actually promises, and $Expected in the runner is empty.

Notes for review

• Design doc: docs/superpowers/specs/2026-07-19-gui-profile-theme-design.md.
• Engine sources are listed explicitly in cmake/EngineSources.cmake — the new files are registered there.
• Script follows TORQUE_SCRIPT.md (one class per file, onAdd/onRemove ownership, class/superclass with init()).
• 140 files, +18.8k/−2.7k. It reads far better commit by commit than as one diff; each message explains the why and the traps found along the way.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01C5SkVxmwBq2TV52GbeBRLU