-
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
Add restore recently closed panes #11471
Add restore recently closed panes #11471
Conversation
- Keep a buffer of panes/tabs that were closed recently in the form of a list of actions to remake it. - To restore the pane or tab just run the list of actions. - This (deliberately) does not restore the exact visual state as focus could have changed / new panes might have been created in the mean time. Mostly this means that restoring a pane will just attach to the currently focused pane instead of whatever its old neighbor was.
2021-10-09.15-27-45.mp4 |
Also I understand that the next release is probably 2021-10-15 and this probably won't get into 1.12 |
@@ -474,6 +474,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 comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't we check the size of _previouslyClosedPanesAndTabs
in this function? (like how we do in _CloseFocusedPane
)
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 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.
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.
Honestly, this is just a nit and a question. I'm cool signing off on this, but I wanna make sure we've considered the parent pane situation first.
The code looks great, the implementation is simple and straightforward, thanks!
|
||
_AddPreviouslyClosedPaneOrTab(std::move(actions)); | ||
} | ||
else if (tab.try_as<SettingsTab>()) |
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 almost seems like TabBase
should have a virtual method like BuildStartupActions
that both TerminalTab
and SettingsTab
override with their specific implementations...
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.
that seems reasonable.
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.
yea I'm cool with this
Ping on this. Not sure if people are out for the holiday season yet. |
new year ping. |
@DHowett that means you. There was a reason you had me assign you last month, I'm sure of it (but I can't remember why) |
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)); | ||
} | ||
|
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,
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've talked with @DHowett and he's fine with me being second on this. Let's do it and see how it rolls.
Hello @zadjii-msft! 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 (
|
I'm free~~~. A number of the items on 9800 can probably be updated as well since they have been fixed / are stale. |
Thanks so much for doing this 😄 |
🎉 Handy links: |
Summary of the Pull Request
Add an action to restore the last closed pane or tab. When all you have is restoring last sessions everything looks like a
std::vector<ActionAndArgs>
.References
#9800
PR Checklist
Detailed Description of the Pull Request / Additional comments
of actions to remake it.
have changed / new panes might have been created in the mean time. Mostly
this means that restoring a pane will just attach to the currently focused
pane instead of whatever its old neighbor was.
standards, but prevents complaints about there being memory leaks in long running
instances.
Validation Steps Performed