Make exit code behavior more disacoverable #10798
Comments
superm1
added
the
Issue-Feature
ghost
added
Needs-Triage
Cool idea :) /cc @cinnamon-msft
This exists already. |
TIL. It's on a per-OS-profile basis. |
|
I'm okay with adding something like
But only in the scenario where it's only displayed the first time it happens, because otherwise I feel like it just adds noise. Fortunately, with #8324, we can actually do this. Thanks for the idea! |
zadjii-msft
added
Area-User Interface
zadjii-msft
removed
the
Needs-Triage
|
it's this by design? I have ran into this issue aswell, I use terminal to connect to multiple servers, and especially when I want to close a pane I split before to check something extra, I want the pane to close when I exit the session. Now it seems to be stuck and I can't get my screenspace back. I also have no way of closing that pane without closing the entire tab, that can't be by design? Example (obfuscated IP and username information for obvious reasons): Or should I create a seperate issue for this? Edit: I am an idiot, you can close it with the keybinding obviously, but it would be nice if it closed by design when you exit an SSH session for example :) |
Definitely! That's why we made this configurable with the |
@zadjii-msft - how do you envision the UX of this. I believe it should be an InfoBar with "Don't show this message again" button rather then printing some text into the terminal. Probably something like: |
## Summary of the Pull Request * Introduces info bar shown upon session failure, that guides the user how to configure termination behavior * Allows this info bar to be dismissed permanently (choice stored in state) * Allows "keyboard service" info bar to be dismissed permanently ## PR Checklist * [x] Closes #10798, #8699 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated. * [ ] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments UI: * Introduce an additional info bar for "close on exit" configuration tip * Stack this bar after "keyboard service" bar * Add "Don't show again" button to both bars Dismiss Permanently: * Introduce a set of "dismissed messages" to the Application State * Add verification the message is not dismissed before showing an info bar * "Don't show again" persists the choice under "dismissed messages" Wiring the Info Bar: * Register `TerminalPage` on `TermControl`'s `ConnectionStateChanged` event * Once event is triggered check whether the state is failure * If so and the message was not dismissed permanently, show the info bar
ghost
added
Resolution-Fix-Committed
|
🎉This issue was addressed in #11139, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #11139, which has now been successfully released as Handy links: |
|
Today, I got the CloseOnExitInfoBar for the first time. I then pressed Ctrl+Shift+W to close the tab, but the info bar remained there. Should the info bar be local to the tab or even to the pane? I suppose it shouldn't, because KeyboardServiceWarningInfoBar and SetAsDefaultInfoBar aren't local either, and because the info bar shows up on nonzero exit codes even if Windows Terminal has already been configured to close the tab regardless. If the info bar is not local to the tab, then its location between the tab bar (when the title bar is hidden) and the terminal panes feels misleading. Should it instead be above the tab bar or below the terminal panes? How can I close the info bar by using the keyboard? |
well that's not what you want. I'll file that.
You're... not wrong here. It's maybe not the best place for it, but on top of the tabs would look insane, and probably wouldn't even work easily, given the way we reparent the tab row into the titlebar. In the pane itself would make more sense, but that runs abreast of all sorts of things like #9024, #4998, which might make more sense.
That, that we could probably fix. |
Fixes #11606 This is weird, but the infobars would appear totally on top of the TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar obscuring the tabs. Now, the infobars are strictly inserted after the tabs, before the content. So when they appear, they will reduce the amount of space usable for the control. That is a little annoying, but preferable to the tabs totally not existing. Relevant conversation notes from #10798: > > If the info bar is not local to the tab, then its location between the tab > > bar (when the title bar is hidden) and the terminal panes feels > > misleading. Should it instead be above the tab bar or below the terminal > > panes? > > You're... not wrong here. It's maybe not the best place for it, but _on top_ > of the tabs would look insane, and probably wouldn't even work easily, given > the way we reparent the tab row into the titlebar. > > In the pane itself would make more sense, but that runs abreast of all sorts > of things like #9024, #4998, which might make more sense. I'm just gonna go with this now, because it's _better_ than before, while we work out what's _best_.
…of (#11609) Fixes #11606 This is weird, but the infobars would appear totally on top of the TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar obscuring the tabs. Now, the infobars are strictly inserted after the tabs, before the content. So when they appear, they will reduce the amount of space usable for the control. That is a little annoying, but preferable to the tabs totally not existing. Relevant conversation notes from #10798: > > If the info bar is not local to the tab, then its location between the tab > > bar (when the title bar is hidden) and the terminal panes feels > > misleading. Should it instead be above the tab bar or below the terminal > > panes? > > You're... not wrong here. It's maybe not the best place for it, but _on top_ > of the tabs would look insane, and probably wouldn't even work easily, given > the way we reparent the tab row into the titlebar. > > In the pane itself would make more sense, but that runs abreast of all sorts > of things like #9024, #4998, which might make more sense. I'm just gonna go with this now, because it's _better_ than before, while we work out what's _best_. 
…of (#11609) Fixes #11606 This is weird, but the infobars would appear totally on top of the TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar obscuring the tabs. Now, the infobars are strictly inserted after the tabs, before the content. So when they appear, they will reduce the amount of space usable for the control. That is a little annoying, but preferable to the tabs totally not existing. Relevant conversation notes from #10798: > > If the info bar is not local to the tab, then its location between the tab > > bar (when the title bar is hidden) and the terminal panes feels > > misleading. Should it instead be above the tab bar or below the terminal > > panes? > > You're... not wrong here. It's maybe not the best place for it, but _on top_ > of the tabs would look insane, and probably wouldn't even work easily, given > the way we reparent the tab row into the titlebar. > > In the pane itself would make more sense, but that runs abreast of all sorts > of things like #9024, #4998, which might make more sense. I'm just gonna go with this now, because it's _better_ than before, while we work out what's _best_.  (cherry picked from commit a916a5d)
…of (#11609) Fixes #11606 This is weird, but the infobars would appear totally on top of the TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar obscuring the tabs. Now, the infobars are strictly inserted after the tabs, before the content. So when they appear, they will reduce the amount of space usable for the control. That is a little annoying, but preferable to the tabs totally not existing. Relevant conversation notes from #10798: > > If the info bar is not local to the tab, then its location between the tab > > bar (when the title bar is hidden) and the terminal panes feels > > misleading. Should it instead be above the tab bar or below the terminal > > panes? > > You're... not wrong here. It's maybe not the best place for it, but _on top_ > of the tabs would look insane, and probably wouldn't even work easily, given > the way we reparent the tab row into the titlebar. > > In the pane itself would make more sense, but that runs abreast of all sorts > of things like #9024, #4998, which might make more sense. I'm just gonna go with this now, because it's _better_ than before, while we work out what's _best_.  (cherry picked from commit a916a5d)
Description of the new feature/enhancement
When a process exits with a return code while closing a terminal, the following message shows up (assuming exit 130)
It's difficult to know what this means, especially if it's while closing a pane. If a process returns an exit code that is non zero, I can't figure out how to get rid of that pane now. Example:
This inevitably leads eventually to #5214
Proposed technical implementation details (optional)
Add a clearer message why this happened, and how to change it.
Then in the GUI add a new option that will control adding
The text was updated successfully, but these errors were encountered: