Background

PR #2026 fixed a multi-pan regression where changing mode on a non-RADE slice would tear down RADE on a different slice. The root-cause fix landed in three places:

• VfoWidget.cpp — added if (m_radeActive) guard before emit radeActivated(false, ...)
• MainWindow.cpp — both radeActivated handlers now check else if (sliceId == m_radeSliceId) deactivateRADE()
• MainWindow.cpp — activateRADE/deactivateRADE use spectrumForSlice() instead of spectrum()

The MainWindow sliceId == m_radeSliceId guard is load-bearing and squashes the bug regardless of upstream emit behavior — the codebase is functionally correct as merged.

What's missing

RxApplet.cpp:396 emits the same radeActivated(false, ...) signal unconditionally — same pattern that VfoWidget had before #2026 patched it:

// RxApplet.cpp (current — line 396):
emit radeActivated(false, m_slice ? m_slice->sliceId() : -1);

vs the now-fixed VfoWidget:

// VfoWidget.cpp (fixed in #2026):
if (m_radeActive)
    emit radeActivated(false, m_slice ? m_slice->sliceId() : -1);

The MainWindow guard makes this redundant emit harmless today, but the asymmetry is worth cleaning up for defense-in-depth: anyone reading RxApplet.cpp would expect the same guard pattern as VfoWidget, and a future MainWindow refactor could remove the load-bearing check on the assumption that "no one fires spurious false signals."

Suggested fix

Apply the same guard to RxApplet.cpp:396:

if (m_radeActive)
    emit radeActivated(false, m_slice ? m_slice->sliceId() : -1);

Verify m_radeActive exists on RxApplet (it does on VfoWidget); add it if not. Should be ~3 lines including the guard tracking.

References

• Merged PR introducing the asymmetry: fix: RADE deactivated by mode change on unrelated slice in multi-pan setup #2026 (great fix, this is just a follow-up cleanup)
• Original RADE multi-pan diagnosis: NF0T's PR description in fix: RADE deactivated by mode change on unrelated slice in multi-pan setup #2026