-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Teach CommandPalette model to natively support tabs and command lines #8420
Conversation
New misspellings found, please review:
To accept these changes, run the following commands
✏️ Contributor please read thisBy default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.
If the listed items are:
See the 🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The :check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉
|
@DHowett , @zadjii-msft - the first one in the saga. Probably the most interesting one since it affects interface:
It also fixes a crash in terminal - I will extract it as a separate PR |
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 very, very good. I love it. I have reviewed 27/31 (waiting to review CommandPalette.* just yet).
I have one question, though, about the overarching design.
Why'd you choose to dispatch three different types of event and make palette item management internal to the command palette? Is it just to hide the implementation details from the caller?
I wonder if there's a design that uses a single event, "I selected a thing, you can figure out what it is on your own," to decouple the palette even further form what it hosts?
In addition -- I know there'd be some code duplication, so it would be pretty annoying -- could PaletteItem become an interface? If it becomes an interface, TabBase itself could conform to the interface (it has all the same properties, and already does notifications for them(!)) (EDIT: it doesn't have KeyChordText, but... there actually are key chords that activate tabs!)
Perhaps that's too much coupling. I'm not sure how I feel, having suggested it.
This is an amazing start.
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, Name, _PropertyChangedHandlers); | ||
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, Icon, _PropertyChangedHandlers); | ||
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, KeyChordText, _PropertyChangedHandlers); | ||
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, FilterableValue, _PropertyChangedHandlers); |
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.
FilterableValue not mentioned in the idl!
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.
Sorry.. It was a part of the idl at some moment.. but then I decided to postpone this feature (until we generalize the filterable list.. and realized it will be implemented differently).. unfortunately, I forgot to cleanup it from the header..
I was hesitating about that a lot.. the translation between the generic Item and the specific one should happen somewhere (either in the TerminalPage or in the palette). I decided to do it in the Palette.. not to complicate the Page even more... So the current idea is:
Here I was hesitating as well - to allocate tons of objects or do some coupling. But then I assumed that since the number of objects is overall low, it's better to decouple (isn't the gang of four all about composition rather than inheritance? 😊)
|
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.
Okay, I understand it all, and it makes a lot of code WAY easier to read. I'm a go for this, but on the single condition of please keep going. I'm looking forward to where this is going.
@@ -28,14 +28,12 @@ namespace winrt::TerminalApp::implementation | |||
WINRT_CALLBACK(PropertyChanged, Windows::UI::Xaml::Data::PropertyChangedEventHandler); | |||
|
|||
// The TabViewIndex is the index this Tab object resides in TerminalPage's _tabs vector. | |||
// This is needed since Tab is going to be managing its own SwitchToTab command. | |||
GETSET_PROPERTY(uint32_t, TabViewIndex, 0); |
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.
Note to future self: TabViewIndex
is still needed, just not for the SwitchToTab
command
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.
@zadjii-msft - exactly. This is why I removed the comment, as it was misleading 😊
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, Name, _PropertyChangedHandlers); | ||
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, Icon, _PropertyChangedHandlers); | ||
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, KeyChordText, _PropertyChangedHandlers); | ||
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, FilterableValue, _PropertyChangedHandlers); |
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 FilterableValue
unused?
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.
It is.. sorry... I will reintroduce it in some form, but later on - when extracting a generic filterable list view
_dispatch.DoAction(actionAndArgs); | ||
} | ||
const auto filteredCommand{ selectedCommand.try_as<winrt::TerminalApp::FilteredCommand>() }; | ||
_switchToTab(filteredCommand); |
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.
okay so let me get this right - whenever the selection changes, we'll try to _switchToTab
to that item, regardless if it's an action, commandline, or tab. Then, _switchToTab
will ignore the things it doesn't care about.
I see where this is going in the rest of #8415, with raising separate events for selected vs dispatched items, but right now it feels a little weird
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.
@zadjii-msft - are you addressing the readability or the runtime flow? From the code readability it is still far from perfect, but from the runtime perspective it will be applied only for tabs (as the function is invoked only in TabSwitch mode).
@Don-Vito Any reason this one's still marked a draft? |
@zadjii-msft - this is not a draft anymore 😊 |
Well, not since you marked it as reviewable 😉 I'll put this one on my list! |
I am not sure if this one reviewable even if it is marked as one 😄 |
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 it. It's excellent!
@msftbot merge this in 1 minute |
Hello @DHowett! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
Thanks so much :D |
Glad to work on this 😊 And I guess that more joy is ahead - as now I seem to conflict myself 😄 |
Hello @DHowett! Because this pull request has the Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 8 hours, a condition that will be fulfilled in about -1642 seconds. No worries though, I will be back when the time is right! 😉 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 (
|
kicked |
Very minimal. Those files are used by a build task that isn't even included in the CI build 😄 |
Lol. Sorry. |
#8420 removed `SwitchToTab()` as a responsibility of `TabBase` and replaces `_mruTabActions` with `_mruTabs` (conceptually). This PR fixes the build break by... - replacing `TerminalPage`'s reference to the SettingsTab's SwitchToTab command, with a reference to the tab itself - using that reference to maintain existing tab switching behavior ## References #1564 - Settings UI #8420 - Command Palette + SwitchToTab refactoring ## PR Checklist * [X] Closes #8538 ## Validation Steps Performed ✅ Open SUI --> switch to a different tab --> try opening SUI again --> switches to existing SUI ✅ Open SUI --> switch to a different tab --> reorder tabs --> try opening SUI again --> switches to existing SUI
🎉 Handy links: |
…microsoft#8420) First step towards microsoft#8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
First step towards #8415:
PaletteItem
and derive from it to provide native supportfor tabs and command lines (
ActionPaletteItem
/TabPaletteItem
,CommandLinePaltteItem
)commands and preview tabs externally)