feat(gui): status-bar toast on blocked tune via locked slice#3020
Merged
Conversation
The on-screen LOCKED overlay on the VFO and RX-applet frequency labels catches users whose attention is near the frequency display (scroll, direct entry, band shortcut). Operators using keyboard step, MIDI knobs, or HID encoders may not be looking at the VFO at all — a locked slice could swallow several knob clicks before they notice. Wire MainWindow::onSliceAdded() to SliceModel::lockedFeedbackActiveChanged (introduced in #2983 as part of the centralized LOCKED-feedback gate). On the false→true edge — the first blocked tune of a sustained sequence — show a 3-second status-bar message: "Slice is locked — unlock to tune." Dedup is natural: a stuck MIDI knob or held keyboard arrow generates one toast at the start of the burst, not one per event, because the signal only fires on transition. When the 500 ms feedback timer elapses without another blocked attempt, the gate clears and the next blocked attempt re-triggers the toast. Single message for all paths — operator already knows which input they used; the message just surfaces the lock cause. Matches the existing memory-recall lock toast in MainWindow.cpp. Closes #2984. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Clean and minimal — the signal-driven approach is the right call. Thanks @ten9876.
Looks good:
- Edge-triggered dedup via
lockedFeedbackActiveChanged(true)is the natural fit and covers every blocked-tune entry point without per-call-site state. - Lambda capture + connection receiver are both
this; sender is the slice, so the connection is automatically torn down when the slice is destroyed. No leak, no dangling. - Mirrors the existing memory-recall lock toast pattern (
statusBar()->showMessage(...)with a 3s timeout at MainWindow.cpp:9644) and thelockedFeedbackActiveChangedconsumers in VfoWidget.cpp:2527 / RxApplet.cpp:1855. - Scope is contained: 1 file, +10/-0, no new state in MainWindow.
One small observation (non-blocking):
- If multiple slices fire
lockedFeedbackActiveChanged(true)near-simultaneously (e.g. two locked slices receiving HID/MIDI bursts in different pans), the secondshowMessagecall will replace the first toast at roughly the same text. Harmless in practice — same message, same intent — and not worth latching globally.
Test plan in the PR body covers the dedup behavior well. Approving with a comment per review policy.
🤖 aethersdr-agent · cost: $2.8249 · model: claude-opus-4-7
G6PWY-Chris
pushed a commit
to G6PWY-Chris/AetherSDR
that referenced
this pull request
Jun 22, 2026
…dr#3020) ## Summary Implements aethersdr#2984. Wires `MainWindow::onSliceAdded()` to the new `SliceModel::lockedFeedbackActiveChanged` signal (from aethersdr#2983 / aethersdr#3017) so a 3-second status-bar message fires on the first blocked tune of a sustained sequence: > Slice is locked — unlock to tune. ## Why this is the option-2 path The issue listed two approaches: per-path latches in `nudgeFreq` / `rx.tuneKnob` / HID coalesce, or driving the message off a single SliceModel signal. With aethersdr#2983 landed, the signal route is one connection, automatic dedup (only fires on the false→true edge), and naturally covers every current and future blocked-tune entry point — no per-call-site latch state. ## Dedup behavior `lockedFeedbackActiveChanged(true)` fires once when the LOCKED feedback gate goes active. The 500 ms timer in SliceModel keeps the gate active across rapid repeated blocked attempts (stuck MIDI knob, held arrow key), so a burst gives **one toast at the start**, not one per event. When the timer expires without another block, the gate clears; the next blocked attempt re-triggers a fresh toast. ## Scope - 1 file, +10 / -0 - No new state in MainWindow - Same message for keyboard / MIDI / HID / wheel / direct-entry / band-shortcut paths — operator knows which input they used; the message just surfaces the lock cause - Matches the existing memory-recall lock toast pattern in MainWindow.cpp ## Test plan - [x] Clean build, 0 warnings - [ ] Manual: lock slice, scroll-wheel tune ⇒ LOCKED overlay shows AND status-bar toast appears - [ ] Manual: lock slice, hold keyboard right-arrow for 2s ⇒ overlay shows continuously, ONE toast at start (not spammed) - [ ] Manual: lock slice, spin MIDI tune knob ⇒ same as above - [ ] Manual: unlock slice, scroll-tune ⇒ no toast (gate didn't activate) Closes aethersdr#2984. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements #2984. Wires
MainWindow::onSliceAdded()to the newSliceModel::lockedFeedbackActiveChangedsignal (from #2983 / #3017) so a 3-second status-bar message fires on the first blocked tune of a sustained sequence:Why this is the option-2 path
The issue listed two approaches: per-path latches in
nudgeFreq/rx.tuneKnob/ HID coalesce, or driving the message off a single SliceModel signal. With #2983 landed, the signal route is one connection, automatic dedup (only fires on the false→true edge), and naturally covers every current and future blocked-tune entry point — no per-call-site latch state.Dedup behavior
lockedFeedbackActiveChanged(true)fires once when the LOCKED feedback gate goes active. The 500 ms timer in SliceModel keeps the gate active across rapid repeated blocked attempts (stuck MIDI knob, held arrow key), so a burst gives one toast at the start, not one per event. When the timer expires without another block, the gate clears; the next blocked attempt re-triggers a fresh toast.Scope
Test plan
Closes #2984.
🤖 Generated with Claude Code