[Scenario] Progress Bar Follow-ups #9301

Open
opened 2026-01-31 01:51:10 +00:00 by claunia · 21 comments
Owner

Originally created by @zadjii-msft on GitHub (Jun 27, 2020).

Originally assigned to: @PankajBhojwani on GitHub.

[Original issue: #3004] [Initial PR: #8055] [Display the progress in the tab: #8133]

This is a list of tasks, bugs, etc, related to the "taskbar progress indicator", as first implemented in #8055. While not all of them are immediately relevant for the taskbar indicator, they're all related to the showing of progress state in the Terminal.

Sequence Description

ESC ] 9 ; 4 ; st ; pr ST

Set progress state on Windows taskbar and tab. When `st` is:
  • 0: remove progress.
  • 1: set progress value to pr (number, 0-100).
  • 2: set the taskbar to the "Error" state
  • 3: set the taskbar to the "Indeterminate" state
  • 4: set the taskbar to the "Warning" state

### Follow-up work
- [ ] #7955
- [ ] #1620
- [ ] #8449
- [ ] #9481
- [x] #8910
- [x] #10090
- [x] #9743
- [ ] #3991

"Auto-detect output, display in tab/taskbar" (#7955) and #1620 are very closely related

Bell notifications

These cover some of the same areas of the above, so I'm including them because I feel they deserve a mention here:

  • Make terminal beeps highlight Windows Terminal in the taskbar, to get user attention when backgrounded #1608 -> added in Windows Terminal seems 30x times slower than mintty/wsltty (#8215)
  • show an indicator if there's a bell in the tab #8106 -> added in #8637
  • The bell should "fade out", like it does for browsers
  • More elaborate visual belling -> added in #9270
    • bellStyle: flash -> flash the window. (maybe visual)
    • bellStyle: taskbar -> flash the taskbar (maybe taskbar)
    • bellStyle: visual -> both? (maybe visual|taskbar)
Originally created by @zadjii-msft on GitHub (Jun 27, 2020). Originally assigned to: @PankajBhojwani on GitHub. ##### [Original issue: #3004] [Initial PR: #8055] [Display the progress in the tab: #8133] This is a list of tasks, bugs, etc, related to the "taskbar progress indicator", as first implemented in #8055. While not all of them are immediately relevant for the _taskbar_ indicator, they're all related to the showing of progress state in the Terminal. <table> <thead> <td> Sequence </td> <td> Description </td> </thead> <tr> <td> `ESC ] 9 ; 4 ; st ; pr ST` </td> <td> Set progress state on Windows taskbar and tab. When `st` is: * `0`: remove progress. * `1`: set progress value to `pr` (number, 0-100). * `2`: set the taskbar to the "Error" state * `3`: set the taskbar to the "Indeterminate" state * `4`: set the taskbar to the "Warning" state </td> </tr> </table> ![](https://devblogs.microsoft.com/commandline/wp-content/uploads/sites/33/2021/01/progress-ring.gif) ```[tasklist] ### Follow-up work - [ ] #7955 - [ ] #1620 - [ ] #8449 - [ ] #9481 - [x] #8910 - [x] #10090 - [x] #9743 - [ ] #3991 ``` "Auto-detect output, display in tab/taskbar" (#7955) and #1620 are very closely related ### Bell notifications These cover some of the same areas of the above, so I'm including them because I feel they deserve a mention here: * [x] Make terminal beeps highlight Windows Terminal in the taskbar, to get user attention when backgrounded #1608 -> added in #8215 * [x] show an indicator if there's a bell in the tab #8106 -> added in [#8637](https://github.com/microsoft/terminal/pull/8637) * [ ] The bell should "fade out", like it does for browsers * [x] More elaborate visual belling -> added in #9270 - `bellStyle: flash` -> flash the window. (maybe `visual`) - `bellStyle: taskbar` -> flash the taskbar (maybe `taskbar`) - `bellStyle: visual` -> both? (maybe `visual|taskbar`) ### Related? * #14909
claunia added the Area-VTProduct-TerminalArea-UserInterfaceIssue-Scenario labels 2026-01-31 01:51:11 +00:00
Author
Owner

@ghost commented on GitHub (Jun 27, 2020):

Hi! Thanks for attempting to open an issue. Unfortunately, you didn't write anything in the body which makes it impossible to understand your concern. You are welcome to fix up the issue and try again by opening another issue with the body filled out.

@ghost commented on GitHub (Jun 27, 2020): Hi! Thanks for attempting to open an issue. Unfortunately, you didn't write anything in the body which makes it impossible to understand your concern. You are welcome to fix up the issue and try again by opening another issue with the body filled out.
Author
Owner

@qu1ck commented on GitHub (Nov 30, 2020):

Just some context on how conemu does autodetection of long running operations: if last line starts with [int]% it assumes that it's a progress indicator and sets tab name accordingly and also taskbar state:

image

I would love to see something like this in terminal.

@qu1ck commented on GitHub (Nov 30, 2020): Just some context on how conemu does autodetection of long running operations: if last line starts with [int]% it assumes that it's a progress indicator and sets tab name accordingly and also taskbar state: ![image](https://user-images.githubusercontent.com/3622532/100583622-ca4a7c00-329f-11eb-94e9-9b290630893e.png) I would love to see something like this in terminal.
Author
Owner

@sba923 commented on GitHub (Jan 28, 2021):

Just installed Preview v1.6.10272.0 and gave that great feature a shot.

Is it intentional that the taskbar (only) reflects the "progress state" of the active tab? I know that it's not possible to display multiple states there, but shouldn't it be possible to display the result of some combination? For instance, if any tab is "busy", then the taskbar says "busy", if tab 1 is at 50% and tab 2 is at 75%, then the taskbar shows 62.5%?

@sba923 commented on GitHub (Jan 28, 2021): Just installed [Preview v1.6.10272.0](https://github.com/microsoft/terminal/releases/tag/v1.6.10272.0) and gave that great feature a shot. Is it intentional that the taskbar (only) reflects the "progress state" of the _active_ tab? I know that it's not possible to display _multiple_ states there, but shouldn't it be possible to display the result of some _combination_? For instance, if any tab is "busy", then the taskbar says "busy", if tab 1 is at 50% and tab 2 is at 75%, then the taskbar shows 62.5%?
Author
Owner

@DHowett commented on GitHub (Jan 28, 2021):

It is intentional.

@DHowett commented on GitHub (Jan 28, 2021): It is intentional.
Author
Owner

@zadjii-msft commented on GitHub (Jan 28, 2021):

It doesn't seem like a bad idea to combine these states somehow (with a setting), but we'd want to make sure we're clear what happens in cases like:

  • one tab has progress=N%, another tab has no progress
  • one tab has progress=N%, another tab has progress=M%
  • one tab has progress=N%, another tab has progress=indeterminate
  • one tab has progress=N%, another tab has progress=M% AND is in the error state

etc.

@zadjii-msft commented on GitHub (Jan 28, 2021): It doesn't seem like a bad idea to combine these states somehow (with a setting), but we'd want to make sure we're clear what happens in cases like: * one tab has progress=N%, another tab has no progress * one tab has progress=N%, another tab has progress=M% * one tab has progress=N%, another tab has progress=indeterminate * one tab has progress=N%, another tab has progress=M% AND is in the error state etc.
Author
Owner

@sba923 commented on GitHub (Jan 29, 2021):

It doesn't seem like a bad idea to combine these states somehow (with a setting), but we'd want to make sure we're clear what happens in cases like:

  • one tab has progress=N%, another tab has no progress
  • one tab has progress=N%, another tab has progress=M%
  • one tab has progress=N%, another tab has progress=indeterminate
  • one tab has progress=N%, another tab has progress=M% AND is in the error state

etc.

Sure, we have to specify this exhaustively.

@sba923 commented on GitHub (Jan 29, 2021): > It doesn't seem like a bad idea to combine these states somehow (with a setting), but we'd want to make sure we're clear what happens in cases like: > > * one tab has progress=N%, another tab has no progress > * one tab has progress=N%, another tab has progress=M% > * one tab has progress=N%, another tab has progress=indeterminate > * one tab has progress=N%, another tab has progress=M% AND is in the error state > > etc. Sure, we have to specify this exhaustively.
Author
Owner

@sba923 commented on GitHub (Jan 29, 2021):

I can't seem to see a visible difference between ESC ] 9 ; 4 ; 2 ST (Error) and ESC ] 9 ; 4 ; 4 ST (Warning or Pause, what's the official 'name'?).

Do I miss something?

@sba923 commented on GitHub (Jan 29, 2021): I can't seem to see a visible difference between `ESC ] 9 ; 4 ; 2 ST` (Error) and `ESC ] 9 ; 4 ; 4 ST` (Warning or Pause, what's the official 'name'?). Do I miss something?
Author
Owner

@zadjii-msft commented on GitHub (Jan 29, 2021):

"warning": ^[]9;4;4;100^G
image

"error": ^[]9;4;2;100^G
image

One is yellow, the other is red...

@zadjii-msft commented on GitHub (Jan 29, 2021): "warning": `^[]9;4;4;100^G` ![image](https://user-images.githubusercontent.com/18356694/106296678-96e08b00-6217-11eb-903d-27e5d8253ca9.png) "error": `^[]9;4;2;100^G` ![image](https://user-images.githubusercontent.com/18356694/106296822-becfee80-6217-11eb-86ea-f6a2ac7e95c3.png) One is yellow, the other is red...
Author
Owner

@sba923 commented on GitHub (Jan 29, 2021):

"warning": ^[]9;4;4;100^G
image

"error": ^[]9;4;2;100^G
image

One is yellow, the other is red...

Oh... reading #8055 and experimenting, I had not guessed / understood that the pr argument must be present, even when useless. It doesn't seem needed for 0 and 3, but now I know that a dummy non-zero argument must be there for 2 and 4...

@sba923 commented on GitHub (Jan 29, 2021): > "warning": `^[]9;4;4;100^G` > ![image](https://user-images.githubusercontent.com/18356694/106296678-96e08b00-6217-11eb-903d-27e5d8253ca9.png) > > "error": `^[]9;4;2;100^G` > ![image](https://user-images.githubusercontent.com/18356694/106296822-becfee80-6217-11eb-86ea-f6a2ac7e95c3.png) > > One is yellow, the other is red... Oh... reading #8055 and experimenting, I had not guessed / understood that the `pr` argument *must* be present, even when useless. It doesn't seem needed for 0 and 3, but now I know that a dummy non-zero argument must be there for 2 and 4...
Author
Owner

@tringi commented on GitHub (Feb 1, 2021):

It doesn't seem like a bad idea to combine these states somehow (with a setting), but we'd want to make sure we're clear what happens in cases like:

  • one tab has progress=N%, another tab has no progress
  • one tab has progress=N%, another tab has progress=M%
  • one tab has progress=N%, another tab has progress=indeterminate
  • one tab has progress=N%, another tab has progress=M% AND is in the error state

etc.

Sure, we have to specify this exhaustively.

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.

@tringi commented on GitHub (Feb 1, 2021): > > It doesn't seem like a bad idea to combine these states somehow (with a setting), but we'd want to make sure we're clear what happens in cases like: > > > > * one tab has progress=N%, another tab has no progress > > * one tab has progress=N%, another tab has progress=M% > > * one tab has progress=N%, another tab has progress=indeterminate > > * one tab has progress=N%, another tab has progress=M% AND is in the error state > > > > etc. > > Sure, we have to specify this exhaustively. It is specified in [Taskbar API here](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) how progress bars are combined for multiple windows collapsed into single button. For consistency it would be good idea to duplicate the behavior.
Author
Owner

@zadjii-msft commented on GitHub (Feb 1, 2021):

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.

image

Thanks for that. We should do that.

@zadjii-msft commented on GitHub (Feb 1, 2021): > It is specified in [Taskbar API here](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) how progress bars are combined for multiple windows collapsed into single button. For consistency it would be good idea to duplicate the behavior. ![image](https://user-images.githubusercontent.com/18356694/106458450-05ab2780-6456-11eb-8aa6-d5e8adcde68f.png) Thanks for that. We should do **that**.
Author
Owner

@WSLUser commented on GitHub (Feb 3, 2021):

FYI, this WinUI bug still exists: https://github.com/microsoft/microsoft-ui-xaml/issues/3787

@WSLUser commented on GitHub (Feb 3, 2021): FYI, this WinUI bug still exists: https://github.com/microsoft/microsoft-ui-xaml/issues/3787
Author
Owner

@sba923 commented on GitHub (Feb 8, 2021):

On at least two of my systems ESC ] 9 ; 4 ; 3 ; 100 BEL does cause the rotating symbol on the Windows Terminal tab, but doesn't trigger the animation on the taskbar button. Shall I open a separate issue for that?

@sba923 commented on GitHub (Feb 8, 2021): On at least two of my systems `ESC ] 9 ; 4 ; 3 ; 100 BEL` does cause the rotating symbol on the Windows Terminal tab, but doesn't trigger the animation on the taskbar button. Shall I open a separate issue for that?
Author
Owner

@sba923 commented on GitHub (Mar 4, 2021):

On at least two of my systems ESC ] 9 ; 4 ; 3 ; 100 BEL does cause the rotating symbol on the Windows Terminal tab, but doesn't trigger the animation on the taskbar button. Shall I open a separate issue for that?

Opened https://github.com/microsoft/terminal/issues/9374

@sba923 commented on GitHub (Mar 4, 2021): > On at least two of my systems `ESC ] 9 ; 4 ; 3 ; 100 BEL` does cause the rotating symbol on the Windows Terminal tab, but doesn't trigger the animation on the taskbar button. Shall I open a separate issue for that? Opened https://github.com/microsoft/terminal/issues/9374
Author
Owner

@tringi commented on GitHub (Mar 5, 2021):

A little off topic, but wouldn't it be trivial to add this also to Conhost? Just simply forward the command to ITaskbarList3?

Thinking about it... now that this is open, I might even try myself.

@tringi commented on GitHub (Mar 5, 2021): A little off topic, but wouldn't it be trivial to add this also to Conhost? Just simply forward the command to ITaskbarList3? Thinking about it... now that this is open, I might even try myself.
Author
Owner

@sba923 commented on GitHub (Mar 16, 2021):

On at least two of my systems ESC ] 9 ; 4 ; 3 ; 100 BEL does cause the rotating symbol on the Windows Terminal tab, but doesn't trigger the animation on the taskbar button. Shall I open a separate issue for that?

Opened #9374

#9374 closed with solution by @DHowett: one must enable animations under Settings / Ease of Access / Display:

image

Without this, only OSC9;4;x;yST with x=1,2,4 are fully functional.

@sba923 commented on GitHub (Mar 16, 2021): > > On at least two of my systems `ESC ] 9 ; 4 ; 3 ; 100 BEL` does cause the rotating symbol on the Windows Terminal tab, but doesn't trigger the animation on the taskbar button. Shall I open a separate issue for that? > > Opened #9374 #9374 closed with solution by @DHowett: one must enable animations under Settings / Ease of Access / Display: ![image](https://user-images.githubusercontent.com/12860484/111352027-0acdda00-8684-11eb-96ba-07b923456e58.png) Without this, only `OSC9;4;x;yST` with x=1,2,4 are fully functional.
Author
Owner

@sba923 commented on GitHub (Sep 7, 2022):

On at least two of my systems ESC ] 9 ; 4 ; 3 ; 100 BEL does cause the rotating symbol on the Windows Terminal tab, but doesn't trigger the animation on the taskbar button. Shall I open a separate issue for that?

Opened #9374

#9374 closed with solution by @DHowett: one must enable animations under Settings / Ease of Access / Display:

Here's the state of affairs on this issue:

  1. on one system, even with "Show Animations in Windows" set to "on", the animation's still missing
  2. on the same system, the "Show Animations in Windows" setting keeps turning itself off

This has been discussed in https://github.com/microsoft/terminal/issues/9374 up to the point where I created https://aka.ms/AAehwy4, and from there no progress has been made.

@sba923 commented on GitHub (Sep 7, 2022): > > > On at least two of my systems `ESC ] 9 ; 4 ; 3 ; 100 BEL` does cause the rotating symbol on the Windows Terminal tab, but doesn't trigger the animation on the taskbar button. Shall I open a separate issue for that? > > > > > > Opened #9374 > > #9374 closed with solution by @DHowett: one must enable animations under Settings / Ease of Access / Display: Here's the state of affairs on this issue: 1. on one system, even with "Show Animations in Windows" set to "on", the animation's still missing 2. on the same system, the "Show Animations in Windows" setting keeps turning itself off This has been discussed in https://github.com/microsoft/terminal/issues/9374 up to the point where I created https://aka.ms/AAehwy4, and from there no progress has been made.
Author
Owner

@aetonsi commented on GitHub (Mar 9, 2023):

Hi, is there, anywhere, a clear documentation about all of these behaviors? If not, would it be possible to add a brief section in the Console Virtual Terminal Sequences page (if that's the correct location)?

I'm asking because i have a couple of quick questions but i can't find the answer anywhere, the information is pretty fragmented (it seems to me). I'm going to place them here in case anyone has an answer.

First question
It's possible to switch from "progress" (green taskbar) status to "error"/"warning" status (red/yellow) without altering and without even knowing the current progress percentage. This is possible by using st=2/4 (error/warning) combined with pr= (empty string).
For example, if the status bar is currently 33% in "progress" (green) status, using st=2 and pr= i can go to 33% "error" (red) status.
The question is: is it possible to do the same but in the opposite direction? meaning, for example, is it possible to go from 33% "error" status to the same percentage but in "progress" status?
I tried st=1 and pr= /-1/0 either do nothing or simply reset the taskbar (as if st was 0)

Second question
In #8055 it is said:

We've also extended this with:

  • st 3: set indeterminate state
  • st 4: set paused state

What it is meant with "paused state"? is it referring to conemu's "warning" state? or is it some additional/custom WindowsTerminal's feature?


thank you everyone

@aetonsi commented on GitHub (Mar 9, 2023): Hi, is there, anywhere, a clear documentation about all of these behaviors? If not, would it be possible to add a brief section in the [Console Virtual Terminal Sequences](https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequencesx) page (if that's the correct location)? I'm asking because i have a couple of quick questions but i can't find the answer anywhere, the information is pretty fragmented (it seems to me). I'm going to place them here in case anyone has an answer. **First question** It's possible to switch from "progress" (green taskbar) status to "error"/"warning" status (red/yellow) without altering and without even knowing the current progress percentage. This is possible by using `st`=`2`/`4` (error/warning) combined with `pr`=` ` (empty string). For example, if the status bar is currently 33% in "progress" (green) status, using `st`=`2` and `pr`=` ` i can go to 33% "error" (red) status. The question is: is it possible to do the same but in the opposite direction? meaning, for example, is it possible to go from 33% "error" status to _the same_ percentage but in "progress" status? I tried `st`=`1` and `pr`=` `/`-1`/`0` either do nothing or simply reset the taskbar (as if `st` was `0`) **Second question** In #8055 it is said: > We've also extended this with: > - st 3: set indeterminate state > - st 4: set paused state What it is meant with "paused state"? is it referring to conemu's "warning" state? or is it some additional/custom WindowsTerminal's feature? --- thank you everyone
Author
Owner

@j4james commented on GitHub (Mar 9, 2023):

The question is: is it possible to do the same but in the opposite direction? meaning, for example, is it possible to go from 33% "error" status to the same percentage but in "progress" status?

No. The default percent value for an error state is the whatever current percent is (that's why you can change from st=1 to st=2 without setting the percent), but the default percent value for the progress state is 0. In other words, if you set st=1 with no percent, you're getting 0%, which is the same as disabling the progress.

What it is meant with "paused state"? is it referring to conemu's "warning" state?

Yes. At the time this feature was being developed, ConEmu had only documented states 0, 1, and 2. I think state 3 may already have been implemented, but not yet documented. State 4 was then proposed by Windows Terminal, but it was discussed with the Maximus5 first, who agreed to add matching functionality to ConEmu. The ConEmu documentation now includes all 5 states (see ConEmu specific OSC).

@j4james commented on GitHub (Mar 9, 2023): > The question is: is it possible to do the same but in the opposite direction? meaning, for example, is it possible to go from 33% "error" status to _the same_ percentage but in "progress" status? No. The default percent value for an error state is the whatever current percent is (that's why you can change from st=1 to st=2 without setting the percent), but the default percent value for the progress state is 0. In other words, if you set st=1 with no percent, you're getting 0%, which is the same as disabling the progress. > What it is meant with "paused state"? is it referring to conemu's "warning" state? Yes. At the time this feature was being developed, ConEmu had only documented states 0, 1, and 2. I think state 3 may already have been implemented, but not yet documented. State 4 was then proposed by Windows Terminal, but it was discussed with the Maximus5 first, who agreed to add matching functionality to ConEmu. The ConEmu documentation now includes all 5 states (see [ConEmu specific OSC](https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC)).
Author
Owner

@aetonsi commented on GitHub (Mar 10, 2023):

No. The default percent value for an error state is the whatever current percent is (that's why you can change from st=1 to st=2 without setting the percent), but the default percent value for the progress state is 0. In other words, if you set st=1 with no percent, you're getting 0%, which is the same as disabling the progress.

Is this a Windows default?

Is there a system API to read the current progress percentage? Because if there is, it would nice if WindowsTerminal's behaviour was more consistent, maintaining the current percentage whenever pr= , even when going from st=2/4 to st=1 (by first reading the current "error"/"warning" percentage, then applying the "progress" state with that percentage).

If you deem this to be too misleading, because it wouldn't match the OS' behaviour, i'd just like to know if a WT escape code/API/something to get the current percentage exists, so that i can use it in my utilities to achieve the aforementioned behaviour. Something like the ESC[6n escape code which "returns" the cursor position in the stdin stream (even though i don't know how to read the returned value...)

@aetonsi commented on GitHub (Mar 10, 2023): > No. The default percent value for an error state is the whatever current percent is (that's why you can change from st=1 to st=2 without setting the percent), but the default percent value for the progress state is 0. In other words, if you set st=1 with no percent, you're getting 0%, which is the same as disabling the progress. Is this a Windows default? Is there a system API to read the current progress percentage? Because if there is, it would nice if WindowsTerminal's behaviour was more consistent, maintaining the current percentage whenever `pr`=` `, even when going from `st`=`2`/`4` to `st`=`1` (by first reading the current "error"/"warning" percentage, then applying the "progress" state with that percentage). If you deem this to be too misleading, because it wouldn't match the OS' behaviour, i'd just like to know if a WT escape code/API/something to get the current percentage exists, so that i can use it in my utilities to achieve the aforementioned behaviour. Something like the `ESC[6n` escape code which "returns" the cursor position in the stdin stream (even though i don't know how to read the returned value...)
Author
Owner

@j4james commented on GitHub (Mar 10, 2023):

Is this a Windows default?

No. That's the way it was defined by ConEmu. We're just following their specification.

i'd just like to know if a WT escape code/API/something to get the current percentage exists

No. The simplest option would be for you to keep track of the last percentage value yourself, since I'm assuming you're the one that set it. But if that's not an option for you, then I don't have any other ideas.

@j4james commented on GitHub (Mar 10, 2023): > Is this a Windows default? No. That's the way it was defined by ConEmu. We're just following their specification. > i'd just like to know if a WT escape code/API/something to get the current percentage exists No. The simplest option would be for you to keep track of the last percentage value yourself, since I'm assuming you're the one that set it. But if that's not an option for you, then I don't have any other ideas.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9301