Skip to content

[ux] Cancel frequency entry with Escape#1954

Merged
ten9876 merged 1 commit intoten9876:mainfrom
jensenpat:aether/goto-frequency-esc-cancel
Apr 25, 2026
Merged

[ux] Cancel frequency entry with Escape#1954
ten9876 merged 1 commit intoten9876:mainfrom
jensenpat:aether/goto-frequency-esc-cancel

Conversation

@jensenpat
Copy link
Copy Markdown
Collaborator

Summary

  • Add explicit Escape/Cancel handling for VFO direct frequency entry.
  • Apply the same cancel behavior to the RX applet inline frequency editor.
  • Restore the normal frequency display and clear edit focus without committing a tune request.

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

  • Install an event filter on the VFO and RX applet frequency line edits.
  • Handle both QEvent::ShortcutOverride and QEvent::KeyPress for Escape/Cancel so the inline editor wins before application-wide shortcuts can intercept the key.
  • Factor VFO cancellation into cancelDirectEntry() so the source state, displayed value, stacked-widget page, and focus cleanup stay together.

Validation

  • Built successfully with cmake --build build --parallel 10.
  • Ran ctest --test-dir build --output-on-failure -j10; no tests were registered in this build directory.
  • Manual verification by @jensenpat: G opens frequency entry and Escape now cancels the edit without tuning.

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

@jensenpat jensenpat changed the title Cancel frequency entry with Escape [ux] Cancel frequency entry with Escape Apr 25, 2026
@jensenpat jensenpat marked this pull request as ready for review April 25, 2026 13:23
@jensenpat jensenpat requested a review from ten9876 as a code owner April 25, 2026 13:23
Copy link
Copy Markdown
Contributor

@aethersdr-agent aethersdr-agent Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean, well-scoped PR. The approach is correct and the implementation looks solid.

What works well:

  • Handling both QEvent::ShortcutOverride and QEvent::KeyPress is 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 — beginDirectEntry has 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_directEntrySource to 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!

@ten9876 ten9876 merged commit 8602697 into ten9876:main Apr 25, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants