Skip to content
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

Merged
7 commits merged into from
Aug 26, 2022
Merged

Add action for closing all unfocused panes #13547

7 commits merged into from
Aug 26, 2022

Conversation

JerBast
Copy link
Contributor

@JerBast JerBast commented Jul 20, 2022

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).

gif

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

@ghost ghost added Area-UserInterface Issues pertaining to the user interface of the Console or Terminal Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal. labels Jul 20, 2022
@JerBast
Copy link
Contributor Author

JerBast commented Jul 21, 2022

Is it desired to play the closing animation when this action is being used?

@zadjii-msft
Copy link
Member

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 ☺️ We can always add the animations back in post, if we figure out it's possible.

@JerBast
Copy link
Contributor Author

JerBast commented Jul 21, 2022

if you wanna do this without the animation at first

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

@github-actions

This comment has been minimized.

@JerBast JerBast marked this pull request as ready for review July 25, 2022 08:30
doc/cascadia/profiles.schema.json Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/AppActionHandlers.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/TabManagement.cpp Outdated Show resolved Hide resolved
@github-actions

This comment has been minimized.

Copy link
Member

@carlos-zamora carlos-zamora left a 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?

src/cascadia/TerminalApp/AppActionHandlers.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/AppActionHandlers.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/TabManagement.cpp Outdated Show resolved Hide resolved
@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jul 27, 2022
@JerBast
Copy link
Contributor Author

JerBast commented Jul 27, 2022

Thank you for reviewing @carlos-zamora. To answer your 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?

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).

For animations, this respects the "Pane animations" setting in Settings UI > Appearance right?

Yes, that setting is respected because the existing closing animation that performs the check is reused.

@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jul 27, 2022
@carlos-zamora
Copy link
Member

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!

@carlos-zamora carlos-zamora added the Needs-Discussion Something that requires a team discussion before we can proceed label Jul 28, 2022
@zadjii-msft
Copy link
Member

a8d88f26-4180-490b-a894-81cb98541c80
30b113bb-e5a6-4212-bcc7-a6ff17c6fc95

I dunno if this really needs discussion - this seems like it makes sense to me

@zadjii-msft
Copy link
Member

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/?

@zadjii-msft zadjii-msft added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Discussion Something that requires a team discussion before we can proceed labels Aug 15, 2022
@JerBast
Copy link
Contributor Author

JerBast commented Aug 16, 2022

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.

@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 16, 2022
Copy link
Member

@carlos-zamora carlos-zamora left a 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 :)

Copy link
Member

@zadjii-msft zadjii-msft left a 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 now ids 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 😞)

Comment on lines +860 to +865
pane->ClosedByParent([ids{ std::move(paneIds) }, weakThis{ get_weak() }, weakTab]() {
if (auto strongThis{ weakThis.get() })
{
strongThis->_ClosePanes(weakTab, std::move(ids));
}
});
Copy link
Member

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.

Copy link
Contributor Author

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!)

Comment on lines 771 to 773
if (const auto control{ pane->GetTerminalControl() })
{
if (control.ReadOnly())
Copy link
Member

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

Copy link
Contributor Author

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)

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 25, 2022
@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 26, 2022
Copy link
Member

@zadjii-msft zadjii-msft left a 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!

@zadjii-msft zadjii-msft added the AutoMerge Marked for automatic merge by the bot when requirements are met label Aug 26, 2022
@ghost
Copy link

ghost commented Aug 26, 2022

Hello @zadjii-msft!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 0ca1356 into microsoft:main Aug 26, 2022
@ghost
Copy link

ghost commented Sep 13, 2022

🎉Windows Terminal Preview v1.16.252 has been released which incorporates this pull request.:tada:

Handy links:

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-UserInterface Issues pertaining to the user interface of the Console or Terminal AutoMerge Marked for automatic merge by the bot when requirements are met Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add "Close All Other Panes" Action to Settings/Actions
4 participants