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 the PanAdapter is undocked (popped out into its own floating window), the
entire AetherSDR UI becomes unresponsive — mouse clicks, keyboard input, and
controls in all panels stop responding. The freeze persists for as long as the
PanAdapter remains detached. Docking it back into the main window immediately
restores normal operation.

What I expected

The UI should remain fully responsive when the PanAdapter is running as a
floating window. All controls (VfoWidget, AppletPanel, RxApplet, etc.) should
continue to function independently of the PanAdapter's docked/undocked state.

Steps to reproduce

1. Launch AetherSDR and connect to the radio.
2. Wait for the spectrum / waterfall to appear in the PanAdapter.
3. Pop out the PanAdapter into a floating window (undock it).
4. Attempt to interact with any UI element — VFO dial, AppletPanel buttons,
   RxApplet sliders, etc.
5. Observe: UI is frozen / unresponsive.
6. Re-dock the PanAdapter back into the main window.
7. Observe: UI immediately becomes responsive again.

Environment

• AetherSDR version: v0.8.17 (also present in earlier versions)
• OS: macOS Tahoe 26.4.1
• Radio model: not specified
• Firmware: not specified

Note: The freeze-on-undock / recover-on-redock pattern strongly suggests
the main event loop or a Qt paint/render lock is being held by the
SpectrumWidget or PanadapterStack while it is in a floating QDockWidget
or QDialog state. Possible causes include a mutex being acquired on the
main thread by the VITA-49 rendering path, or a QWidget::update() /
repaint() call blocking on the detached window's backing store.

Suggested fix

1. Check for main-thread blocking in SpectrumWidget: look for any
   QMutex::lock() / std::mutex::lock() calls on the GUI thread inside
   updateSpectrum(), updateWaterfallRow(), or paintEvent(). If the
   VITA-49 consumer thread is holding a lock that paintEvent() also needs,
   the main thread will stall while the window is reparented.

2. Audit the pop-out mechanism: if the PanAdapter is detached into a
   QDialog or top-level QWidget, verify that the event loop for the
   detached window is not accidentally consuming events that should go to the
   main window (e.g. exec() called on a modal dialog path instead of
   show()).

3. macOS-specific: on macOS, QWidget::setParent() during undock causes
   a full widget recreation; if SpectrumWidget holds platform resources
   (Metal/OpenGL surface, QOpenGLContext) that are not properly
   migrated, the main window's render loop can stall waiting for context
   release. Consider calling makeCurrent() / doneCurrent() around the
   reparent.

4. Use Qt's QElapsedTimer or Instruments (macOS) to confirm which thread
   is blocked and at what call site before applying a fix.

support-bundle-20260419-115651.tar.gz

What did you expect?

No response

Steps to reproduce

No response

Radio model & firmware

No response

Linux distro & Qt version

No response