docs+fix(smartmtr): dead seed call, migration comment, stale extremes (#3750 L1–L3)#3753
Conversation
…#3750 L1-L3) Three low-severity follow-ups to the SmartMTR meter view (#3723): L1 — The pushSmartMtrInput() "seed the at-rest display" call in buildUI() is dead: m_smartMtr is still false there, so the gate early-returns. The real seed is applyMeterView() from the constructor. Replace the call with a comment explaining where seeding actually happens. L2 — DisplaySettings header claimed the legacy "LeanMode" key is migrated "on first read." It's actually an explicit migrateLegacy() at startup; readObj() does no migration. Reword to avoid misleading future readers. L3 — MeterExtremes left stale m_minRaw/m_maxRaw when the sliding window emptied (only m_hasData was cleared). Harmless today (all readers gate on hasData()), but a trap for future readers — clear them too, matching reset(). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Accessibility check findingsThis PR touches
See Findings are warnings only — the build is not blocked. |
There was a problem hiding this comment.
Reviewed against the code on the branch — all three items check out, and the diff is exactly the scope described (comment-only + two trivial lines, no behavior change).
L1 — dead seed call ✓ Confirmed. m_smartMtr defaults to false (VfoWidget.h:292), buildUI() runs from the constructor while it's still false, and pushSmartMtrInput() early-returns on !m_smartMtr (VfoWidget.cpp:3306) — so the old call was a genuine no-op. The real seed is applyMeterView(), which calls pushSmartMtrInput() at line 3194 immediately after buildUI(). The replacement comment correctly points there.
L2 — migration comment ✓ Confirmed. readObj() does no migration (just a plain AppSettings["Display"] read), and DisplaySettings::migrateLegacy() is the actual migrator, called once at startup from MainWindow.cpp:971. The reworded comment is accurate; the old "on first read" claim was misleading.
L3 — stale raw min/max ✓ Confirmed and consistent. m_minRaw/m_maxRaw are member-initialized to 0.0 (MeterExtremes.h:186-187) and reset() sets the same (lines 43-44), so clearing them on the empty-window path matches both. Today's readers (extremesOpacity, extremeLabels in SmartMtrWidget.cpp) all gate on extremesActive()/hasData() first, so this is correctly characterized as a latent-trap fix rather than a live bug.
Clean, well-scoped, and each change is justified by an accurate reading of the surrounding code. No AppSettings/RAII/C++20 concerns, no null-pointer or resource issues, nothing outside the stated scope. Thanks for the careful write-up tying each fix back to #3723 — made verification quick. LGTM.
🤖 aethersdr-agent · cost: $4.6806 · model: claude-opus-4-8
…ender blank (#3760) ## Summary Disables the identity `QGraphicsOpacityEffect` on fully-enabled SmartMTR option rows so they don't render blank when multiple VFO flags are GPU-composited. A fully-enabled option row keeps its `QGraphicsOpacityEffect` at opacity `1.0` (identity). With the GPU-composited slice flags from #3695, an identity opacity effect can render the row's contents blank. The fix disables the effect entirely while it is at full strength (a disabled `QGraphicsOpacityEffect` is a no-op, so the row paints directly) and keeps it installed only while it is actually dimming the row. ## Provenance This is the net-new fix extracted from #3757. The remainder of that PR re-implemented SmartMTR `#3750` hardening that already landed via #3751 (H1), #3752 (M1–M4), and #3753 (L1–L3); #3757 is being closed in favor of this focused change to avoid re-churning already-merged code. Part of #3750. ## Test plan - [x] Local build passes (`cmake --build build --target AetherSDR`) - [ ] Behavior verified on a real radio if applicable — visual (open the SmartMTR option panel with multiple flags up; rows render, not blank) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Addresses the three LOW / nit items from #3750 (SmartMTR fast-follow), all from #3723. Low-risk cleanup; grouped into one PR.
L1 — dead no-op seed call
VfoWidget::buildUI()hadpushSmartMtrInput(); // seed the at-rest display, butm_smartMtris stillfalseduringbuildUI(), so the gate added in #3723 early-returns — the call does nothing. The real seed isapplyMeterView(), run from the constructor when the persisted choice is SmartMTR. Replaced the dead call with a comment pointing at where seeding happens.L2 — misleading migration comment
DisplaySettings.hclaimed the legacy flat"LeanMode"key is "migrated into this blob on first read." It isn't — migration is an explicitmigrateLegacy()call at startup;readObj()does no migration. Reworded so a future maintainer doesn't assume read-time migration safety.L3 — stale raw min/max on empty extremes window
MeterExtremes::tick()leftm_minRaw/m_maxRawat their previous values when the sliding window emptied (onlym_hasDatawas cleared). Harmless today — every reader (drawExtremes,extremeLabels,extremesOpacity) gates onhasData()/extremesActive()first — but a latent trap for any future reader ofminRaw()/maxRaw(). Clear them to0.0, matchingreset()and the member initializers.Scope: comment-only + 2 trivial lines, no behavior change. No S-meter path impact.
🤖 Generated with Claude Code