-
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 action for closing all unfocused panes #13547
Conversation
Is it desired to play the closing animation when this action is being used? |
That might be cool, but I suspect that's Hard, so if you wanna do this without the animation at first, I'd be all for that |
Yes, that is the current state of the PR 😉. I'm not sure what would be a good way to perform the closing animation sequentially when multiple panes are being closed. My current guess would be to trigger the removal of the next pane after the animation of the previous pane is finished |
This comment has been minimized.
This comment has been minimized.
…ead-only pane is kept
This comment has been minimized.
This comment has been minimized.
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.
A few questions:
- For read-only panes, you say it's similar to closing a single pane. So like, when you invoke the
closeOtherPanes
action, you immediately get the pop-up for all of them? Or do you get the pop-up when it tries to delete the read-only pane? I'm wondering if the expected behavior might be to skip over read-only panes? - For animations, this respects the "Pane animations" setting in Settings UI > Appearance right?
Thank you for reviewing @carlos-zamora. To answer your questions:
The pop-up is only shown when trying to close the pane, not immediately after invoking the action. Skipping read-only panes might be a good solution, but you should probably let the user know why some panes were not closed (for clarity).
Yes, that setting is respected because the existing closing animation that performs the check is reused. |
…en there are no unfocused panes
Nice! I'm gonna add the Needs-Discussion tag just to discuss the read-only panes thing with the team at Monday's meeting. Want to make sure we have behavior we're comfortable with. 😊 Other than that, this PR is looking great! Thank you so much for doing this! |
Hey so we finally had team discussion today - consensus was that we've had enough issues in the past of context dialogs popping in the middle of something happening. We should just blanket skip all read-only panes, to just avoid the issue entirely. This sound good to you/? |
Hey, thanks for discussing this internally. Changing the behaviour for read-only panes sounds good to me and I will make sure to change it before the end of this week. |
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 great! Thanks for doing this! Sorry it took us a bit to get to 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.
Okay maybe I'm missing something. 90% of this looks really good.
- I'm blocking over the one parent/readonly check in
TerminalPage::_PaneConfirmCloseReadOnly
. We should really bring that back. - The recursion in
TerminalPage::_ClosePanes
is maybe a bit tricky to follow. It's not clear to me (just from reading the code) how the loop is ever used...- We add the callback to the pane we're going to close
- We call pane.close
- If the pane is the parent of the pane to be closed, it calls _CloseChild
- in there we trigger the callback
- we pop off the last id off the
ids
- {we do this dance again}
- eventually we return out of the top
_HandleClosePaneRequested
, and nowids
is empty and we exit the loop immediately.
If we can do it just with the loop, that seems easier than the recursion with the callback.
Everything else looks totally 👍 though!
(sorry for the delays 😞)
pane->ClosedByParent([ids{ std::move(paneIds) }, weakThis{ get_weak() }, weakTab]() { | ||
if (auto strongThis{ weakThis.get() }) | ||
{ | ||
strongThis->_ClosePanes(weakTab, std::move(ids)); | ||
} | ||
}); |
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 do we need both the while loop, and the recursion here? Seems like we move the ids
into the callback, but then we shouldn't need the ids again, right? Since the callback now owns that vector...
Maybe I'm missing something.
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.
The loop is used to deal with the case where one of the panes can no longer be found in the tree. Otherwise we cannot guarantee the removal of the other panes in case something like this araises.
The recursion is used to reduce code duplication for the chained removal of the panes (since the pane itself is removed from the tree after the animation finishes). This used to be a simple loop in 11bba27 where the pane was detached before before closing it, bypassing the animation.
(No need to apologise for the delay(s). It is perfectly understandable!)
if (const auto control{ pane->GetTerminalControl() }) | ||
{ | ||
if (control.ReadOnly()) |
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 used to be a pane->ContainsReadOnly
call, replaced now with checking if the actual control in the pane is read-only.
Technically, you can select a parent pane. So you could close a parent pane (and close all the leaves within it). I think with this change, we've lost the ability to check if any leaves in a pane are read-only.
A simple fix might be to just add an else (pane->ContainsReadOnly())
after the if (const auto control
block, and repeat the walking we had before in that block. A little duplicated, but
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.
As the 'response' to a read-only pane is the same in this case (for parents and leaf nodes), I replaced the existing read-only check with the pane->ContainsReadOnly
check and changed the toggling accordingly to avoid duplication (f5a1347)
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 satisfied with that explanation, thanks!
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 (
|
🎉 Handy links: |
This PR introduces a new action for closing all unfocused / other panes within a tab.
Edit (17-08-2022): Read-only panes are ignored when this action is being used (i.e., left open).
Validation Steps Performed
The action was manually tested by applying it to various 'compositions' of panes. This includes tests on read-only panes.
Closes #12216