[ux] Add audio device prompt suppression controls

[jensenpat]

Summary

• Add a Don't ask me again checkbox to the Audio Device Detected dialog.
• Persist that choice as SuppressAudioDeviceNotifications=True in AppSettings so future new-device notifications can be permanently suppressed.
• Respect the persisted suppression setting in the audio device hotplug flow while preserving the existing fallback that resets missing selected devices to the system default.
• Add an inverse-linked Prompt on Audio Device Changes checkbox in Radio Setup > Audio > PC Audio Devices so users can re-enable or disable prompting from settings.
• Document both controls in the audio pipeline hotplug section.

Behavior Notes

The dialog-level checkbox is intentionally one-way from the prompt itself: checking Don't ask me again suppresses future new audio device prompts whether the current dialog is accepted or canceled. The Radio Setup checkbox is the user-facing toggle for changing that preference later: checked means prompts are enabled; unchecked means SuppressAudioDeviceNotifications=True is active.

The suppression gate only bypasses new-device selection prompts. Removal handling is left intact, so if the selected input or output disappears, AetherSDR still clears that stale selection and falls back to the current system default as before.

Validation

• cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo
• cmake --build build -j22
  • Passed after rerunning the macOS app build outside the sandbox for iconutil, per project build guidance.
• ctest --test-dir build --output-on-failure -j22
  • 15/15 tests passed.
• Manually verified by @jensenpat in the built app.

👨🏼‍💻 Generated with OpenAI Codex (GPT-5.5 Pro 4/23) and tested by @jensenpat

[aethersdr-agent]

Thanks @jensenpat — this looks good. The implementation matches AetherSDR conventions cleanly:

• Uses AppSettings::instance() with the "True"/"False" string idiom that's standard across the codebase.
• Placement of the suppression gate after the !deviceAdded early return preserves the removal-fallback path (clearing a missing selected device to system default) even when the prompt is suppressed — which matches what you describe in the PR body.
• The Radio Setup checkbox uses this as the connection context, so the binding cleans up correctly with the dialog.
• Documentation is updated and the dialog stylesheet picks up the new QCheckBox rules.

A couple of small, non-blocking observations:

1. Duplicated key constant. kSuppressAudioDeviceNotificationsKey is defined identically in both MainWindow.cpp and RadioSetupDialog.cpp. If this setting grows additional consumers (e.g. AppSettings migration code), consider promoting it to a shared header alongside the other audio setting keys. Not worth churn for this PR alone.

2. Coordination with #2913. That open PR (fix(audio): suppress Linux hotplug dialog when current selection still works) edits the same handleAudioDeviceListChanged() flow. The two changes are logically complementary (it suppresses spurious prompts when the existing selection is still valid; this gives the user a manual escape hatch), but whichever lands second will need a small rebase. Worth a heads-up to the other PR's author.

3. Persisting suppression on Cancel. As you noted in the PR body, checking "Don't ask me again" and clicking Cancel still persists the suppression. This is a reasonable UX choice given the Radio Setup checkbox is the documented re-enable path, and the docs change makes that discoverable. Just flagging that you've already considered it.

LGTM on functionality, conventions, and scope. No blocking concerns from me.

[ten9876]

Claude here — merged. Thanks @jensenpat, this is the right opt-out
mechanism for the audio-device-detected dialog.

What stood out on review:

The inverse-linked UI handling — "Don't ask me again" in the popup
(natural negative phrasing) ↔ "Prompt on Audio Device Changes" in
Settings (natural positive phrasing) — with explicit conversion at
each boundary. Both surfaces read/write the same AppSettings key,
so user state can't drift between them.

The critical design detail: suppression bypasses the selection
prompt, NOT the removal fallback. Without that carve-out, an
operator who set "don't ask me again" would have their audio break
when their selected device unplugged, with no way to recover.
Keeping `resetMissingAudioDevicesToDefault` outside the suppression
gate means the safety net stays armed even when the user has opted
out of prompts.

Persistence on either OK or Cancel is also right — if the user has
clicked "don't ask me again," that's an expression of intent
orthogonal to whether they accept this particular dialog.

Ships in v26.5.3.

73,
Jeremy KK7GWY & Claude (AI dev partner)