-
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
Display ATS tabs in MRU order #7952
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.
What happens if we re-order the tabs? Won't we not update the indicies in _mruTabActions
, causing the MRU order to be reflective only of the positions the tabs were in, not the actual tabs themselves?
@@ -672,6 +666,7 @@ namespace winrt::TerminalApp::implementation | |||
// Add the new tab to the list of our tabs. | |||
auto newTabImpl = winrt::make_self<Tab>(profileGuid, term); | |||
_tabs.Append(*newTabImpl); | |||
_mruTabActions.Append(newTabImpl->SwitchToTabCommand()); |
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 this line necessary? Won't the new tab be appended automatically in _UpdatedSelectedTab
?
I suppose it doesn't really matter. The redundancy is nice, especially if we ever have a way to open new tabs without automatically switching to them
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 kinda thought of _UpdatedSelectedTab
as the function that does things when a Tab is focused, so it assumes that the Tab already exists in the list when it's called. That's why for MRU, _UpdatedSelectedTab
doesn't append a new tab, it drags and drops the focused tab to the top of MRU. Then the adding of a new Tab/SwitchToTabCommand should be done by CreateNewTabFromSettings
.
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 that's fine.
I make a call to update the indices of |
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.
Ah okay, I see how it works now. Thanks for clarifying!
@@ -672,6 +666,7 @@ namespace winrt::TerminalApp::implementation | |||
// Add the new tab to the list of our tabs. | |||
auto newTabImpl = winrt::make_self<Tab>(profileGuid, term); | |||
_tabs.Append(*newTabImpl); | |||
_mruTabActions.Append(newTabImpl->SwitchToTabCommand()); |
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 that's fine.
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.
Elegant!
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 (
|
This PR changes the ATS display order to _always_ be in most recently used (MRU) order. I chose not to give ATS the option to be displayed in-order because that order is better served through the traditional left-right TabRow switching. _Note_: `TabSearch` will stay in-order. This means that users can only choose one order or another in their `nextTab/prevTab` bindings. Setting `useTabSwitcher` to true will make nT/pT open the ATS in MRU order. If it's set to false, the ATS won't open and nT/pT will simply go left and right on the TabRow. I'm open to getting rid of the global and making ATS its own keybinding, but for now I figured I would keep the current behavior and open the PR to get eyes on the code that doesn't have anything to do with the settings. Closes #973 (cherry picked from commit 00f5fba)
…8076) ## Summary of the Pull Request Changes the way the `useTabSwitcher` setting works. It now accepts either a boolean or a string: * `true`, `"mru"`: Use the tab switcher with MRU tab switching * `"inOrder"`: Use the tab switcher, with in-order tab switching * `false`, `"disabled"`: Don't use the tab switcher. Tabs will switch in-order. This is following the discussion chronicled in #8025, as well as the follow-up investigation in that thread. ## References * #7952 introduced MRU tab switching ## PR Checklist * [x] Closes #8025 - there's also discussion of using a parameter in an action to override this setting, but that should get punted to a follow-up task * [x] I work here * [x] Tests added/passed - YOU BET THEY WERE * [ ] Requires documentation to be updated ## Validation Steps Performed I've been switching tabs all day and all night, with different settings values, and hot-reloading the setting. I also _ran the test_ I added.
🎉 Handy links: |
🎉 Handy links: |
It seems, to achive the MRU behavior, you need to set the Note: Valid as of version |
This PR changes the ATS display order to always be in most recently
used (MRU) order. I chose not to give ATS the option to be displayed
in-order because that order is better served through the traditional
left-right TabRow switching.
Note:
TabSearch
will stay in-order.This means that users can only choose one order or another in their
nextTab/prevTab
bindings. SettinguseTabSwitcher
to true will makenT/pT open the ATS in MRU order. If it's set to false, the ATS won't
open and nT/pT will simply go left and right on the TabRow.
I'm open to getting rid of the global and making ATS its own keybinding,
but for now I figured I would keep the current behavior and open the PR
to get eyes on the code that doesn't have anything to do with the
settings.
Closes #973