-
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
Add IDs to Commands #16904
Add IDs to Commands #16904
Conversation
// - Example: The "SendInput 'abc'" action will have the generated ID "User.sendInput.<hash of 'abc'>" | ||
// Return Value: | ||
// - The ID, based on the ShortcutAction and the Args | ||
winrt::hstring ActionAndArgs::GenerateID() const |
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.
These IDs are very similar to our InternalActionID
except instead of also hashing the ShortcutAction
, we only hash the Args
and we leave the ShortcutAction
as a string. Since these will end up in the user file, I prefer this as it will be more readable
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 is clever, thanks!
// we need to generate an ID for a command in the user settings if it doesn't already have one | ||
auto actionMap{ winrt::get_self<ActionMap>(userSettings.globals->ActionMap()) }; | ||
fixedUp = actionMap->GenerateIDsForActions() || fixedUp; |
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.
Since we aren't actually using these IDs yet, this could definitely be moved into the follow up PR that is actually going to refactor our maps to use the new IDs. However then that leaves this PR as just "adding an ID
field to Command
and barely populating them anywhere". I'm okay with either if anyone feels strongly about it
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.
nah this is great
Notes from chat: test everything! test the round-trip serialization of a command with and without an ID, etc! |
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.
block for tests!
omg why is this so little code |
This comment has been minimized.
This comment has been minimized.
src/cascadia/TerminalSettingsModel/Resources/en-US/Resources.resw
Outdated
Show resolved
Hide resolved
// - Example: The "SendInput 'abc'" action will have the generated ID "User.sendInput.<hash of 'abc'>" | ||
// Return Value: | ||
// - The ID, based on the ShortcutAction and the Args | ||
winrt::hstring ActionAndArgs::GenerateID() const |
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 is clever, thanks!
// we need to generate an ID for a command in the user settings if it doesn't already have one | ||
auto actionMap{ winrt::get_self<ActionMap>(userSettings.globals->ActionMap()) }; | ||
fixedUp = actionMap->GenerateIDsForActions() || fixedUp; |
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.
nah this is great
FWIW, your and perhaps a better name like |
As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
As laid out in #16816, adds an
ID
field toCommand
.This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID. Also note that for now we will not be allowing IDs for iterable/nested commands.
The follow-up PR is where we will actually use the IDs by referring to commands with them.
Refs #16816
Validation Steps Performed
User-created commands in the settings file get rewritten with generated IDs