-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Introduce KeyMapping and Move TerminalSettings construction #7537
Conversation
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.
As far as I can see this looks pretty good, but I'd like to get other eyes on it too bc there's a lot here 😄
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.
This looks like mainly mechanical moves to me. I'm fine with this. But I'd like @DHowett to also sign as he's been closer to this shuffling than me.
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 love love love this. Just some fit and finish stuff.
@@ -1030,8 +1030,7 @@ namespace winrt::TerminalApp::implementation | |||
const auto& profileGuid = focusedTab->GetFocusedProfile(); | |||
if (profileGuid.has_value()) | |||
{ | |||
const auto settingsImpl{ winrt::get_self<implementation::CascadiaSettings>(_settings) }; | |||
const auto settings = settingsImpl->BuildSettings(profileGuid.value()); | |||
const auto settings{ winrt::make<TerminalSettings>(_settings, profileGuid.value(), *_bindings) }; |
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.
how is this different from BuildSettings?
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.
Function | Params |
---|---|
Constructor |
CascadiaSettings, guid, IKeyBindings |
BuildSettings |
CascadiaSettings, NewTerminalArgs, IKeyBindings |
Before, they were both BuildSettings
. But the second BuildSettings
needs to return a tuple so we can't just make that another constructor :(
…osoft/Terminal into dev/cazamor/set/key-mapping
Hello @DHowett! 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 (
|
🎉 Handy links: |
KeyMapping
was introduced to break upAppKeyBindings
.KeyMapping
records the keybindings from the JSON and lets you query them.
AppKeyBindings
now just holds aShortcutActionDispatcher
to runactions, and a
KeyMapping
to record/query your existing keybindings.This refactor allows
KeyMapping
to be moved to theTerminalSettingsModel, and
ShortcutActionDispatcher
andAppKeyBindings
will stay in TerminalApp.AppKeyBindings
had to be passed down to a terminal viaTerminalSettings
. Since each settings object had its ownresponsibility to update/create a
TerminalSettings
object, I moved allof that logic to
TerminalSettings
. This helps with theTerminalSettingsModel refactor, and makes the construction of
TerminalSettings
a bit cleaner and more centralized.References
#885 - this is all in preparation for the TerminalSettingsModel
Validation Steps Performed