Title: Allow independent FFT line and fill colors in Theme Editor

[tw350]

Request preparation

• I used an AI assistant to help structure this request
• I checked for existing issues covering the same feature

What would you like?

Summary
Currently the panadapter FFT trace's fill (the shaded area under/behind the spectrum line) appears to be derived from the same color as the line itself (e.g., via alpha blending), rather than being independently configurable. It'd be great to expose the fill as its own themeable color, separate from the line/stroke color.
Motivation

Lets users pick a bright/high-contrast line color for readability while choosing a more subdued or differently-hued fill for aesthetics or to reduce visual fatigue on long operating sessions.
Matches patterns in other SDR tools (e.g., gqrx exposes a line color + fill toggle, though even there the fill is alpha-derived rather than independently colored — this would be a step further).
Complements the recent ThemeManager token migration work and per-applet Theme Editor overrides already in place for other elements (LIVE chip, highlight/disabled states, etc.).

Proposed implementation
Add a new token, e.g. panadapter.fft.fillColor, alongside the existing line/stroke token.
In the GPU trace renderer, drive the fill pass from its own color/alpha uniform instead of deriving it from the stroke color.
Add a corresponding color picker in the Theme Editor UI, persisted the same way as other per-applet overrides.
Consider whether the 3D stacked-trace mode's floor→peak gradient should remain separate from this, or share the same fill token as a base color.

Scope
2D panadapter FFT trace primarily; 3D stacked-trace mode fill behavior could be addressed as a follow-up if it's architecturally distinct.

[aethersdr-agent]

Triage: confirmed, clear implementation path

Thanks — the request is accurate. The 2D panadapter FFT trace's line and fill share a single color today, so they cannot be tuned independently.

Root cause

There is exactly one client-side color, m_fftFillColor (default cyan #00e5ff, setting key DisplayFftFillColor), declared in src/gui/SpectrumWidget.h:1126. The GPU trace renderer (resources/shaders/panscope.frag) receives it as the single fillColor uniform and uses it for both passes:

• Fill — panscope.frag:89-90: topRgb = fillColor.rgb; botRgb = mix(darkColor.rgb, fillColor.rgb, fa);
• Line/stroke — panscope.frag:131: vec3 lineRgb = heat ? heatColor(t) : fillColor.rgb;

The UBO is packed once in SpectrumWidget.cpp:10297-10322 (float ubo[20] = 5×vec4), with m_fftFillColor written into the fillColor slot and its .darker(300) into darkColor. So the shader has no separate line-color input at all.

Note: color.spectrum.trace (ThemeManager.cpp:437, declared at SpectrumWidget.cpp:1512) exists only as an Inspect-mode hit-target token — it is not consumed by the GPU trace pass, so the trace line color isn't actually theme-driven yet either.

Proposed fix (2D path)

1. New color state — add m_fftLineColor + setFftLineColor()/signal + DisplayFftLineColor persistence, mirroring the existing fill color plumbing (SpectrumWidget.cpp:3049, load at :1671-1676, reset default at MainWindow_Wiring.cpp:3041).
2. Shader — add a 6th vec4 lineColor to the U block in panscope.frag, grow ubo[20] → ubo[24] in SpectrumWidget.cpp, and change line 131 to use lineColor.rgb instead of fillColor.rgb (heat-map path unchanged). The two spare fillP.z/.w pads only hold 2 floats, so a dedicated vec4 is cleaner than stashing RGB there.
3. UI — add a line-color picker next to the existing "FFT Fill" row in SpectrumOverlayMenu.cpp:1468-1514, wired in MainWindow_Wiring.cpp:2633. For the Theme Editor token requested, register color.spectrum.trace (line) as the stroke source and add panadapter.fft.fillColor (or reuse an existing fill token) so both persist as per-applet overrides.

Scope call for the maintainer

• The 3D stacked-trace mode uses a separate software path (SpectrumWidget.cpp:11041-11087) with its own alphaTop/alphaBot gradient off m_fftFillColor. Agree with the reporter that its floor→peak gradient should stay a follow-up; the new line token doesn't affect it.
• Decision needed: should the trace line be driven by the existing color.spectrum.trace theme token (making it fully themeable, a small behavior change to today's m_fftFillColor-drives-line), or keep the overlay-menu picker as the source of truth and only add the fill as a new token? Both are viable; the first is more consistent with the ThemeManager migration goal.

Well-scoped and low-risk apart from the UBO/shader size bump. Ready for aetherclaude-eligible if you want it implemented.

---

_{🤖 aethersdr-agent · cost: $1.5972 · model: claude-opus-4-8}

---

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

Unresolved citations (8)

Citation	Reason
MainWindow_Wiring.cpp:2633	file not found in workspace
MainWindow_Wiring.cpp:3041	file not found in workspace
SpectrumOverlayMenu.cpp:1468-1514	file not found in workspace
SpectrumWidget.cpp:10297-10322	file not found in workspace
SpectrumWidget.cpp:11041-11087	file not found in workspace
SpectrumWidget.cpp:1512	file not found in workspace
SpectrumWidget.cpp:3049	file not found in workspace
ThemeManager.cpp:437	file not found in workspace