Pull request overview

This PR addresses KiwiSDR-induced UI stalls (issue #3816) by moving KiwiSDR client work off the GUI thread, reducing UI-thread workload from Kiwi waterfall delivery, and stabilizing Kiwi FFT trace behavior during pan/zoom gestures to avoid floor “re-anchoring” and trace jumps.

Changes:

• Run KiwiSdrClient instances on a dedicated QThread, routing control calls via invokeMethod() and delivering signals back to the manager/UI via queued connections.
• Coalesce Kiwi waterfall row emissions (min interval) and add gesture-settle signals so remote waterfall view updates aren’t reset on every drag/zoom step.
• Introduce KiwiSdrTraceMath + a focused regression test to keep FFT trace-floor behavior stable across partial/stale row coverage during gestures.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.

Thanks for this, @rfoust — this is a careful, well-structured fix. I checked out the branch and reviewed the threading move, the row coalescing, the pan/zoom gesture handling, and the new trace-math. All 6 CI checks (build, check-macos, check-windows, CodeQL, a11y) are green, and the overall design holds up well.

What's good

• Threading move is done correctly. Clients are moved to a dedicated QThread; all cross-thread calls go through invokeClient() (queued), and all client→manager signals are Qt::QueuedConnection with a client(id) != c staleness guard. The getters (telemetry/state/waterfallAvailable) were correctly switched from direct cross-thread reads to cached m_* maps, which is exactly what makes the move safe. The destructor teardown is also sound: destroyClient(id, /*blocking=*/true) uses BlockingQueuedConnection (guarded by c->thread() != currentThread()) to tear each client down on its own thread before quit()/wait(), and the redundant QThread::finished → deleteLater is harmless.
• saveCurrentWaterfallStreamState move-semantics. Switching the large waterfall QImage/vectors to std::move to avoid COW-detach-and-copy on the GUI thread is a nice, real win.
• Trace-math extraction is clean and properly tested. KiwiSdrTraceMath.h is pure/header-only, and kiwi_sdr_trace_math_test.cpp directly covers the reported symptom — floor stays anchored when a partial/stale row arrives mid-gesture (stabilizeTraceFloor with allowFloorAdapt=false), plus DC-edge mapping and gradual upward adaptation.
• UI-sync coalescing (scheduleKiwiSdrUiSync flag batching) and gesture-gated waterfall view updates (settle signals instead of per-step resets) are the right shape for the stall fix.

One confirmed issue (Copilot's finding is valid)

src/gui/MainWindow.cpp:5844 — the unguarded qDebug() in applyPanRangeRequest():

if (!kiwiSdrProfileForPan(panId).isEmpty()) {
    qDebug() << "Pan range request:" << source
             << "center" << centerMhz ...;
    return;
}

This sits on the early-return path taken for every Kiwi pan/zoom range request, and frequencyRangeChangeRequested fires repeatedly during zoom-drag gestures — so this logs at gesture frequency and does string formatting on the GUI thread, in precisely the hot path this PR is trying to keep responsive. Suggest removing it, or gating behind a qCDebug(<category>) so it's off unless the category is enabled.

Minor (non-blocking)

• On pan-drag release, m_draggingPan is set false before applyPanDragCenter(..., force=true) and the subsequent emit panDragSettled(...), so the centerChangeRequested handler and panDragSettled can both drive updateKiwiWaterfallView once. It's idempotent so no harm — just noting it's a double-commit on release.

Nothing here blocks; the one actionable item is the hot-path qDebug. Nice work on the threading discipline and the regression test.

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

Reviewed the substantive pieces in depth — strong, expert-level work.

Threading (highest-risk): single worker QThread; clients created parentless + moveToThread'd with deleteLater-on-finished; all client→manager signals QueuedConnection WITH stale-guards (if (client(id) != c) return) against in-flight queued signals after a client is replaced; GUI→worker via invokeClient (queued); destroyClient's BlockingQueuedConnection correctly guarded (c->thread() != currentThread()) and safe since the worker never waits back on the GUI; shutdown does blocking-destroy each client then quit()+wait(3000) with a setParent(nullptr)+self-delete-on-finish fallback to avoid destroy-while-running; qRegisterMetaType<QVector> for the cross-thread args. The subtle bits most refactors miss are all handled.

Trace math (KiwiSdrTraceMath.h): isolated pure functions with std::isfinite guards throughout (stops a stale/partial bin re-anchoring the floor → the trace jump), area-weighted averaging for zoom-out, graceful fallback, 100-line regression test.

Pan/zoom: settle-timer debounce so a gesture doesn't fire repeated remote Kiwi window resets, and the local drag path owns the visual during an active drag (stale remote rows ignored).

Platform-agnostic, no TX surface, live-verified. The one field watch-point is heavy multi-Kiwi-profile churn, which the stale-guards + blocking-destroy are built for. Thanks @rfoust — this closes the KiwiSDR GUI-thread-lag problem.