-
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
Combine pane taskbar states in the taskbar #10090
Comments
Interesting. There are already some other weird edge cases about the progress state I didn't notice before, but are making testing.... tricky. first
These were fixed in d5a14f9. second
more to follow... |
I'm not sure I totally love this, the way it's exactly specified by the taskbar API. For them, they always combine the states of an entire group of windows, with a priority order. So if there's multiple windows with different states, then "Error" is more important than "Warning", more than "Normal", more than "Indeterminate". IMO, I'd almost expect more nuance to this. It feels weird to have the focused pane be set to indeterminate, then an adjacent pane set to (normal,25), and have the tab and taskbar show (normal,25). I kinda think that the focused pane should always take priority, if it has progress set at all. If it doesn't, then I think we should fall back to the "combine" behavior. Same with the window itself - if the focused tab has a set progress state, let's use that one. Otherwise, we'll fall back to combining the states of all the other tabs. Current progress is in |
The Taskbar rules, prioritizing errors, are designed to bring attention to issues the user can solve, or should be notified. For example: It would be irritating if you had put two copy operations on the background, and once one had finished, the button would turn from green to orange/red, to indicate prompt (e.g. overwrite) at 1%, which you could've solved much sooner and saved time. |
## Summary of the Pull Request ![background-progress-000](https://user-images.githubusercontent.com/18356694/126653006-3ad2fdae-67ae-4cdb-aa46-25d09217e365.gif) This PR causes the Terminal to combine taskbar states at the tab and window level, according to the [MSDN docs for `SetProgressState`](https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-itaskbarlist3-setprogressstate#how-the-taskbar-button-chooses-the-progress-indicator-for-a-group). This allows the Terminal's taskbar icon to continue showing progress information, even if you're in a pane/tab that _doesn't_ have progress state. This is helpful for cases where the user may be running a build in one tab, and working on something else in another. ## References * [`SetProgressState`](https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-itaskbarlist3-setprogressstate#how-the-taskbar-button-chooses-the-progress-indicator-for-a-group) * Progress mega: #6700 ## PR Checklist * [x] Closes #10090 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This also fixes a related bug where transitioning from the "error" or "warning" state directly to the "indeterminate" state would cause the taskbar icon to get stuck in a bad state. ## Validation Steps Performed <details> <summary><code>progress.cmd</code></summary> ```cmd @echo off setlocal enabledelayedexpansion set _type=3 if (%1) == () ( set _type=3 ) else ( set _type=%1 ) if (%_type%) == (0) ( <NUL set /p =�]9;4� echo Cleared progress ) if (%_type%) == (1) ( <NUL set /p =�]9;4;1;25� echo Started progress (normal, 25^) ) if (%_type%) == (2) ( <NUL set /p =�]9;4;2;50� echo Started progress (error, 50^) ) if (%_type%) == (3) ( @Rem start indeterminate progress in the taskbar @Rem this `<NUL set /p =` magic will output the text _without a newline_ <NUL set /p =�]9;4;3� echo Started progress (indeterminate, {omitted}) ) if (%_type%) == (4) ( <NUL set /p =�]9;4;4;75� echo Started progress (warning, 75^) ) ``` </details>
🎉This issue was addressed in #10755, which has now been successfully released as Handy links: |
It is specified in Taskbar API here how progress bars are combined for multiple windows collapsed into single button. For consistency it would be good idea to duplicate the behavior.
Originally posted by @tringi in #6700 (comment)
The text was updated successfully, but these errors were encountered: