[ux] Cancel frequency entry with Escape#1954
Conversation
There was a problem hiding this comment.
Clean, well-scoped PR. The approach is correct and the implementation looks solid.
What works well:
- Handling both
QEvent::ShortcutOverrideandQEvent::KeyPressis the right way to win the Escape key before app-wide shortcuts intercept it. The idempotent guard (currentIndex() != 1/cancelDirectEntry()returning false on second fire) prevents double-execution cleanly. - Factoring VfoWidget's cancel logic into
cancelDirectEntry()is a good call —beginDirectEntryhas a matching counterpart now, and the state reset (source string, displayed text, stack page, focus) stays in one place. - The RxApplet inline version is fine as-is since there's no
m_directEntrySourceto reset there.
One minor observation (non-blocking):
In RxApplet::eventFilter, the Escape handler doesn't null-check m_freqStack before calling m_freqStack->currentIndex(). In practice this is safe because m_freqEdit only exists after buildUI() creates both widgets, but cancelDirectEntry() in VfoWidget is slightly more defensive with its if (!m_freqStack || !m_freqEdit || ...) guard. If you wanted consistency you could add && m_freqStack to the RxApplet condition, but this is genuinely nitpick-level — the crash path doesn't exist in the current code.
No bugs, no resource leaks, no scope creep. Thanks for the contribution, @jensenpat!
Summary
Root Cause
The Go to Frequency shortcut moves focus into the VFO frequency QLineEdit, but the inline editor did not define a cancel path. Pressing Escape could be consumed by Qt's shortcut resolution path or app-wide Escape shortcuts before the line edit received a normal keypress, leaving the frequency entry active instead of canceling it.
User Impact
Operators can press G, reconsider the frequency change, and press Escape to back out cleanly. The same expectation now holds for the RX applet frequency inline editor: Escape closes the editor, leaves the slice frequency unchanged, and returns focus to normal operating shortcuts.
Implementation Notes
Validation
👨🏼💻 Generated with OpenAI Codex (GPT-5.5 Pro 4/23) and tested by @jensenpat