Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

What happened

When a panel or applet is popped out (undocked from the main window) and then
re-docked, the entire AetherSDR UI becomes permanently unresponsive — buttons,
sliders, the VFO dial, and the spectrum widget all stop responding to mouse and
keyboard input. The application process stays alive (no crash), audio continues
(if a connection was active), but no GUI interaction is possible. The only
recovery is to kill and restart the application.

What I expected

After re-docking a popped-out panel the UI should return to normal, fully
interactive operation, exactly as it was before the pop-out.

Steps to reproduce

1. Launch AetherSDR v0.8.12 on macOS Tahoe 26.4.1.
2. Connect to a FlexRadio (or observe behaviour without a radio connected).
3. Pop out any panel / applet from the main window (via the pop-out button or
   equivalent context menu action).
4. Re-dock the same panel back into the main window.
5. Attempt to interact with any GUI element (VFO dial, AppletPanel buttons,
   SpectrumWidget, RxApplet controls, etc.).

Result: All GUI input is ignored; the window is rendered but frozen.
Expected: Normal interactive operation resumes.

Environment

Suggested fix

The freeze is consistent with a Qt event loop blockage or a missed
QSignalBlocker / m_updatingFromModel guard that deadlocks after the
QDockWidget or floating-window state change. Likely candidates:

• A signal connected during pop-out that is not properly disconnected on
  re-dock, causing recursive emission or a mutex deadlock.
• MainWindow's m_updatingFromModel flag being left true after the
  dock/undock cycle, which would silently swallow all subsequent user-input
  signals (the existing guard pattern is documented in CLAUDE.md §GUI↔Radio
  Sync).
• On macOS the QWidget::setParent() call that Qt performs internally during
  re-parenting triggers a QEvent::WinIdChange; if AetherSDR has any
  native-window handles cached (e.g. for CoreAudio's VirtualAudioBridge)
  those handles become stale and any subsequent callback on them can block the
  main thread.

Recommended first diagnostic step: add a qDebug() trace to
MainWindow::eventFilter and the dockLocationChanged / topLevelChanged
slots to confirm whether any signal is received after the re-dock, and whether
m_updatingFromModel is true at that point.

support-bundle-20260414-120730.tar.gz

What did you expect?

No response

Steps to reproduce

No response

Radio model & firmware

No response

Linux distro & Qt version

No response