-
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
Add restore recently closed panes #11471
Changes from 3 commits
96b2b2f
a35ecd2
15bf2e6
a55d56a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -337,6 +337,7 @@ | |
"toggleShaderEffects", | ||
"wt", | ||
"quit", | ||
"restoreLastClosed", | ||
"unbound" | ||
], | ||
"type": "string" | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -392,6 +392,26 @@ namespace winrt::TerminalApp::implementation | |
CATCH_LOG(); | ||
} | ||
|
||
// Method Description: | ||
// - Record the configuration information of the last closed thing . | ||
// - Will occasionally prune the list so it doesn't grow infinitely. | ||
// Arguments: | ||
// - args: the list of actions to take to remake the pane/tab | ||
void TerminalPage::_AddPreviouslyClosedPaneOrTab(std::vector<ActionAndArgs>&& args) | ||
{ | ||
// Just make sure we don't get infinitely large, but still | ||
// maintain a large replay buffer. | ||
if (const auto size = _previouslyClosedPanesAndTabs.size(); size > 150) | ||
{ | ||
const auto it = _previouslyClosedPanesAndTabs.begin(); | ||
// delete 50 at a time so that we don't have to do an erase | ||
// of the buffer every time when at capacity. | ||
_previouslyClosedPanesAndTabs.erase(it, it + (size - 100)); | ||
} | ||
|
||
_previouslyClosedPanesAndTabs.emplace_back(args); | ||
} | ||
|
||
// Method Description: | ||
// - Removes the tab (both TerminalControl and XAML) after prompting for approval | ||
// Arguments: | ||
|
@@ -408,6 +428,23 @@ namespace winrt::TerminalApp::implementation | |
co_return; | ||
} | ||
} | ||
|
||
if (const auto terminalTab = _GetTerminalTabImpl(tab)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why don't we check the size of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I probably just forgot. I added that as an afterthought right before pushing. It probably isn't even necessary overall since the vector in most reasonable cases won't be more than 10s to 100s of KB of data, but I'm curious what everyone's thoughts are on that. |
||
{ | ||
auto actions = terminalTab->BuildStartupActions(); | ||
|
||
_AddPreviouslyClosedPaneOrTab(std::move(actions)); | ||
} | ||
else if (tab.try_as<SettingsTab>()) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this almost seems like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. that seems reasonable. |
||
{ | ||
ActionAndArgs action; | ||
action.Action(ShortcutAction::OpenSettings); | ||
OpenSettingsArgs args{ SettingsTarget::SettingsUI }; | ||
action.Args(args); | ||
|
||
_AddPreviouslyClosedPaneOrTab(std::vector{ std::move(action) }); | ||
} | ||
|
||
_RemoveTab(tab); | ||
} | ||
|
||
|
@@ -710,6 +747,23 @@ namespace winrt::TerminalApp::implementation | |
}); | ||
} | ||
|
||
// Build the list of actions to recreate the closed pane, | ||
zadjii-msft marked this conversation as resolved.
Show resolved
Hide resolved
|
||
// BuildStartupActions returns the "first" pane and the rest of | ||
// its actions are assuming that first pane has been created first. | ||
// This doesn't handle refocusing anything in particular, the | ||
// result will be that the last pane created is focused. In the | ||
// case of a single pane that is the desired behavior anyways. | ||
auto state = pane->BuildStartupActions(0, 1); | ||
{ | ||
ActionAndArgs splitPaneAction{}; | ||
splitPaneAction.Action(ShortcutAction::SplitPane); | ||
SplitPaneArgs splitPaneArgs{ SplitDirection::Automatic, state.firstPane->GetTerminalArgsForPane() }; | ||
splitPaneAction.Args(splitPaneArgs); | ||
|
||
state.args.emplace(state.args.begin(), std::move(splitPaneAction)); | ||
} | ||
_AddPreviouslyClosedPaneOrTab(std::move(state.args)); | ||
|
||
pane->Close(); | ||
} | ||
} | ||
|
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.
Out of curiosity... when this has like 149 actions in it and you restore it... does the Terminal UI wildly flicker as it plays all the actions back until it settles? I'm concerned that either someone will interact with it in some way while it's playing back or that it will look horrendous on a slower system as it recreates a bunch of stuff.
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.
To disambiguate,
_previouslyClosedPanesAndTabs
itself contains vectors of actions, and when you restore the last closed thing it will pop one vector and run all of those. The size limit, whatever it ends up being, shouldn't meaningfully affect the performance of the UI. Technically this erase call will end up calling a memcpy and some destructors, but that should be fast.To answer your intended question, in the video above I show what it looks like to restore a tab with 7 panes in it. It does take a second for it to resolve everything since it is spawning new processes/terminal controls for each one. Of course that is in a debug build so it might be faster in a release build.
I did another test just quickly (still a debug build, with debugger attached), restoring a tab that had 20 powershell panes in it took about ~6 seconds and the UI was unresponsive during that time. That corresponds to ~40 actions being executed: 20 split panes and some move focus to put the panes in the right spots.
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.
Huh, down the line, we should display a message like "setting up your workspace..." or something like that rather than being unresponsive. That'd be some nice polish instead of sitting with an unresponsive UI haha.
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.
Yeah ok. I'm fine with taking it for the sake of getting the useful feature in, but Carlos is right that we should probably add some small polish to it in the future, if someone complains or we feel like 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.
For the case of restoring a single pane, it won't be any slower than if the user did a split pane manually. It is only on the case where someone restores a tab with a bunch of panes on it that it takes some time. There is the benefit of the user (roughly) knowing what they are recreating, so they shouldn't be too surprised if it takes a second.
That being said, this is a fairly naive implementation so there is probably be room for improvement,