-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tunnel F7 keypresses directly into special handlers in TermControl #4807
Conversation
The Xaml input stack doesn't allow an application to suppress the "caret browsing" dialog experience triggered when you press F7. The official recommendation from the Xaml team is to catch F7 before we hand it off. This commit introduces a special F7 handler and an ad-hoc implementation of event bubbling. Runtime classes implementing a custom IF7Listener interface are considered during a modified focus parent walk to determine who can handle F7 specifically. If the recipient control handles F7, we suppress the message completely. This event bubbler has some minor issues -- the search box will not be able to receive F7 because its parent control implements the handler. Since search is already mostly a text box, it doesn't _need_ special caret browsing functionality as far as I can tell. TermControl implements its OnF7Pressed handler by synthesizing a keybindings event and an event to feed into Terminal Core directly. It's not possible to create a synthetic KeyPressRoutedEvent; if it were, I would have just popped one into the traditional input queue. :) Fixes #638.
@@ -7,6 +7,14 @@ namespace Microsoft.Terminal.TerminalControl | |||
delegate void FontSizeChangedEventArgs(Int32 width, Int32 height, Boolean isInitialChange); | |||
delegate void ScrollPositionChangedEventArgs(Int32 viewTop, Int32 viewHeight, Int32 bufferLength); | |||
|
|||
// c++/winrt makes it difficult to share this idl between two projects, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason we don't just define this in the TerminalControl
project, and just reference it as Microsoft.TerminalControl.IF7Listener
in TerminalApp
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I .. honestly don't know why I didn't choose that. It seems wrong for WindowsTerminal.exe to be depending on an interface from all the way down in TerminalControl; it's an app concern, and Control just happens to share the same concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mainly just wondering if we can/should abstract this further away from just F7. But if caret browsing is a SUPER unique scenario, then whatever. Not worth blocking though :)
Hello @DHowett-MSFT! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
The Xaml input stack doesn't allow an application to suppress the "caret
browsing" dialog experience triggered when you press F7.
The official recommendation from the Xaml team is to catch F7 before we
hand it off.
This commit introduces a special F7 handler and an ad-hoc implementation of event bubbling.
Runtime classes implementing a custom IF7Listener interface are
considered during a modified focus parent walk to determine who can
handle F7 specifically.
If the recipient control handles F7, we suppress the message completely.
This event bubbler has some minor issues -- the search box will not be
able to receive F7 because its parent control implements the handler.
Since search is already mostly a text box, it doesn't need special
caret browsing functionality as far as I can tell.
TermControl implements its OnF7Pressed handler by synthesizing a
keybindings event and an event to feed into Terminal Core directly.
It's not possible to create a synthetic KeyPressRoutedEvent; if it were,
I would have just popped one into the traditional input queue. :)
Fixes #638.