[gui] FreeDvReporterModel: migrate hardcoded TX/RX/Msg highlight colors to ThemeManager tokens

[ten9876]

Follow-up to #3439 (merged as 8679cdb). Surfaced during review — the FreeDV Reporter dialog itself uses ThemeManager tokens (`{{color.background.0}}`, `{{color.text.primary}}`, etc.) throughout, but the row-highlight backgrounds in `FreeDvReporterModel.cpp` are still three hardcoded `QColor` constants.

The hardcoded constants

`src/gui/FreeDvReporterModel.cpp:18-20`:

```cpp
const QColor kTxBg {0xfc, 0x45, 0x00}; // orange (#fc4500)
const QColor kRxBg {0x37, 0x9b, 0xaf}; // teal (#379baf)
const QColor kMsgBg{0xe5, 0x8b, 0xe5}; // purple (#e58be5)
```

These drive the row `Qt::BackgroundRole` when a station is actively transmitting (`kTxBg`), recently RX'd (`kRxBg`, fades after a timeout), or has a recent message (`kMsgBg`, fades after a timeout).

Why migrate

1. Theme consistency. Every other surface in the dialog already pulls from ThemeManager — these three constants are the only chrome that doesn't follow the active theme. A future light-mode or high-contrast theme would render the rest of the dialog correctly while leaving these three rows looking off.
2. The TX token already exists. `ThemeManager` already exposes `color.background.tx` (a TX-state background token used elsewhere in the chrome). `kTxBg` should consume that token; if the resolved value differs from `#fc4500`, that's a theme inconsistency worth resolving in the token, not in this file.
3. Accessibility. Per docs/a11y.md "Colour contrast" (added in docs(a11y): add WCAG/POUR grounding, colour contrast, manual-test sections #3443), highlight backgrounds need WCAG 4.5:1 contrast against the foreground text. The current hex values were picked visually; running them through the ThemeManager pipeline lets a future high-contrast theme override them without touching this file.

Existing tokens vs new tokens needed

Constant	Hex	Existing token?	Action
`kTxBg`	`#fc4500` orange	✅ `color.background.tx` exists	Consume it. If the resolved value differs, fix the token, not the file.
`kRxBg`	`#379baf` teal	❌ No `color.background.rx` yet	Add a new token. Suggested: `color.background.rx` (mirrors `.tx` naming).
`kMsgBg`	`#e58be5` purple	❌ No semantic token for "message"	Add a new token. Suggested: `color.background.message` or `color.accent.message`.

Migration sketch

1. Add the two missing tokens (`color.background.rx`, `color.background.message`) to ThemeManager's theme JSON files for each active theme variant.
2. Replace the three `QColor` constants with calls to `ThemeManager::instance().resolveColor(...)` (or whatever the consuming API is for non-stylesheet contexts — TableView background roles are returned as `QVariant` from `data()`, not painted via stylesheets, so this needs the C++ accessor not the `{{token}}` substitution).
3. Verify the highlight expiration tick (`onHighlightTick` at `FreeDvReporterModel.cpp`) still re-renders the row when the resolved color changes — should be automatic via the existing `dataChanged` emit.

Scope notes

• Out of scope: any other model files in `src/gui/` that may have similar hardcoded highlight colors. If grep finds them while touching the theme JSON, separate issue.
• Out of scope: the dialog's existing `{{color.*}}` token usage — that's already correct.

Test plan

• Build clean on all three platforms.
• Visual parity check: open FreeDV Reporter, trigger a TX (other station), an RX, and a message, confirm the three highlight backgrounds render at the resolved colors.
• Theme switch test (if the project has multiple themes wired up): switch theme, confirm highlights change.

Refs #3439

[aethersdr-agent]

Triage — confirmed and ready for maintainer review.

Verified against current source

• The three constants live at src/gui/FreeDvReporterModel.cpp:18-20 exactly as quoted, and feed Qt::BackgroundRole at lines 109/111 (TX / RX / Msg).
• One thing not called out in the issue: kHlFg at line 21 (#000000, used at line 118 for Qt::ForegroundRole) is also hardcoded. Any token migration should cover it too, otherwise a future high-contrast theme that flips the backgrounds will leave the foreground stranded — exactly the inconsistency the migration is meant to prevent.
• ThemeManager exposes QColor ThemeManager::instance().color(token) (see src/core/ThemeManager.h:112). That's the C++ accessor the issue refers to as resolveColor — naming is color(), not resolveColor().

⚠️ One correction to the migration plan

The issue says: "color.background.tx exists — consume it. If the resolved value differs from #fc4500, that's a theme inconsistency worth resolving in the token, not in this file."

This is the part that needs maintainer judgment, because that token is not semantically a row-highlight color. In default-dark.json line 34 it's #3a2a0e — a dark brown chrome tint, used in 35+ places as a subtle "this panel is in TX state" surface color:

• src/gui/StripChainWidget.cpp:73 and ClientChainWidget.cpp:73 — kBgTxActiveDim panel background
• src/gui/HealthApplet.cpp:826,832 — GROUND? / WATCH status pill backgrounds
• src/gui/StripFinalOutputPanel.cpp:877 — button :checked background
• src/gui/ClientCompThresholdFader.cpp:30 — fader handle center
• tools/migrate_colours.py:84-85 — documented as the "TX-active tint" target for migration

So the two options proposed in the issue both have a problem:

1. Change color.background.tx's value to #fc4500 — breaks 35+ existing surfaces that want the subtle brown tint, not bright orange.
2. Use the existing #3a2a0e value here — the FreeDV Reporter row would no longer pop visually; the whole point of the highlight is to make an actively-transmitting station jump out, which #3a2a0e does not do.

The bright orange #fc4500 is a row-highlight color, not a chrome tint — semantically distinct. The migration needs its own token namespace.

Suggested fix shape

Add four new tokens (covering kHlFg too) under a highlight namespace, and consume them in the model:

Constant	New token	Default-dark value
kTxBg	color.highlight.tx	#fc4500
kRxBg	color.highlight.rx	#379baf
kMsgBg	color.highlight.message	#e58be5
kHlFg	color.highlight.fg	#000000

Then in FreeDvReporterModel.cpp:

// at use sites (lines 109, 111, 118) — replace QBrush(kTxBg) etc. with
// QBrush(ThemeManager::instance().color("color.highlight.tx"))

Add the four tokens to both resources/themes/default-dark.json and resources/themes/default-light.json (a light-mode variant should probably re-tune saturation; that's a theme-author call).

The model already emits dataChanged from onHighlightTick for the timeout expiry, so re-rendering on a themeChanged signal would need either (a) a small connect(&ThemeManager::instance(), &ThemeManager::themeChanged, this, [this]{ emit dataChanged(...); }) in the model constructor, or (b) accepting that themes only re-paint on the next 250ms tick (probably fine — theme switches aren't frequent).

Open question for maintainer

Is color.highlight.* the right namespace, or should this live in a scoped container (e.g. freedv-reporter/color.background.tx) since these colors are dialog-specific? The flat-namespace approach is simpler; the scoped approach makes it explicit that these aren't global highlight colors. Either is reasonable — flagging for the choice to be made before implementation.

Out of scope (matches issue)

Other src/gui/*Model.cpp files with hardcoded highlight colors. Quick grep should be run during implementation; any hits become a separate follow-up.

Refs #3439.

---

_{🤖 aethersdr-agent · cost: $3.5975 · model: claude-opus-4-7}

---

_{📍 Citation health check (Foundry Constitution Principle I): 7 resolved, 1 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (1)

Citation	Reason
ClientChainWidget.cpp:73	file not found in workspace

[ten9876]

Related migration target found — disabled-state tokens

While reviewing #3441 (just merged as `25b97f2e`), the same hardcoded-hex pattern surfaced — but in a different shape. Worth folding into the same migration sweep, @NF0T, since the theme-system change is the unifying piece.

What #3441 did

Replaced three `:disabled` pseudo-state tokens on the Reboot Radio button with concrete hex values:

`src/gui/RadioSetupDialog.cpp:608-612`:

```css
QPushButton:disabled {
background: #2a1818;
color: #8a6055;
border-color: #4a2828;
}
```

Reason (preserved as an inline comment): the previous tokens (`color.background.1` / `color.meter.bar.fill` / `color.background.2`) all collapsed to similar dim blue-greys, making the disabled button look absent rather than greyed-out.

Why this belongs in the same migration as the FreeDvReporter constants

	FreeDvReporterModel (this issue's original scope)	RadioSetupDialog Reboot button (#3441)
Constants	`kTxBg` / `kRxBg` / `kMsgBg` (status backgrounds)	`#2a1818` / `#8a6055` / `#4a2828` (disabled-state)
What's wrong with the existing tokens	RX and Msg have no semantic token at all	Disabled-state tokens exist for knobs but not buttons
Resolution	Add `color.background.rx` / `.message`	Add `color.button.background.disabled` / `color.button.foreground.disabled` / `color.button.border.disabled`
Hex values are	Picked visually	Verified-good — Ian validated against the live Radio Setup dialog

ThemeManager already has a precedent for this: `color.knob.background.disabled` and `color.knob.foreground.disabled` are real existing tokens (per the recent token inventory). Extending the pattern to `color.button.*.disabled` keeps the namespace consistent.

Suggested addition to the migration plan

In addition to the three FreeDvReporter token migrations:

4. Add disabled-state button tokens to ThemeManager. Suggested namespace mirroring the existing knob pattern:

   • `color.button.background.disabled` → `#2a1818` (Ian's verified value)
   • `color.button.foreground.disabled` → `#8a6055`
   • `color.button.border.disabled` → `#4a2828`

5. Migrate `RadioSetupDialog.cpp:608-612` to consume those tokens instead of the hardcoded hex. The inline comment can be shortened to a pointer to the new token (or removed entirely once the token name is self-documenting).

Ian's PR #3441 is a clean intermediate state — it closes the visibility bug today with concrete colors that work, and the token migration just changes what value the tokens resolve to without rolling back the contrast fix. The hex values are evidence for what the tokens should be set to, not a rejection of the theme abstraction.

Scope question for the maintainer to call

Two options if you decide to take this on, @NF0T:

• (a) One PR for everything: add all five new tokens (3 FreeDvReporter + 3 button-disabled, since `background.tx` already exists), migrate both files, ship as one theme-consistency PR.
• (b) Two PRs: keep the FreeDvReporter migration separate from the button-disabled migration, since they touch different theme sub-namespaces (`background.` vs `button.`).

Lean (a) personally — the theme-JSON edit is the same shape either way and reviewers see one consistent story. But either works.

Refs #3441