Terminal: Feature Request: Taskbar progress indicator

[dim5]

Description of the new feature/enhancement

Add a taskbar progress indicator for displaying the status of the current long running process (when possible).

For example, this can be helpful to users unpacking files with 7z or running python scripts with tqdm.

ConEmu's documentation.

[zadjii-msft]

I could have sworn we had an internal issue for this feature, but it never got migrated to github it appears....

FOUND IT! MSFT:18258406. Here are the relevant notes:

| sequence | description |
|------------|------------|
| ESC ] 9 ; 4 ; st ; pr ST | Set progress state on Windows 7 taskbar and ConEmu title. When st is 0: remove progress. When st is 1: set progress value to pr (number, 0-100). When st is 2: set error state in progress on Windows 7 taskbar |

Also related documentation: ITaskbarList3::SetProgressValue

We should probably also make sure that we support the TBPF_INDETERMINATE state - for something like our own bcz.cmd, where we don't know how long the operation will take.

In conpty mode, we should just pass these sequences through. There's a good amount of precedent for such sequences in the code already.

EDIT:
We should probably also have a couple settings for controlling this behavior:

• [ ] showProgressInTaskbar (default true) to show the progress in the taskbar entry
• [ ] showProgressInTab (default true) to show the progress in the tab itself.

showProgressInTab can probably be a follow up once https://github.com/microsoft/microsoft-ui-xaml/issues/1386 is complete

[SamuelEnglard]

Would this make a good "starter" issue?

[DHowett-MSFT]

@SamuelEnglard

Perhaps! Anyone’s free to have a crack at any issue they find here unless the team’s actively assigned, and even then they just have to ask. It’s got a couple moving parts, but nothing impossible.

For anyone coming from Windows land: the reason the existing solution (calling GetConsoleWindow and using the Shell APIs directly to set progress on the window) doesn’t work is that GetConsoleWindow is an absolute abomination of an API and we never should have let a windowless application access the window it just happened to be hosted in. Circumventing the console and telling the shell to paint progress isn’t even something we can detect; we need applications to move to a standards-compliant or, at the least, _quasi-_ standards-compliant, mechanism for setting progress.

[zadjii-msft]

More to the point, the work that I think is involved here is roughly:

• [ ] Change the OutputStateMachineEngine to be able to parse these sequences and _pass them through_ to the connected terminal, when the console is operating as a conpty. (this might already work).
• [ ] When the state machine isn't in conpty mode, it'll need to call methods on ITerminalDispatch. These should be left unimplemented for conhost. I believe that means no-op'ing them in adaptDispatch, or probably just returning false.
• [ ] For the Windows Terminal, these ITerminalDispatch methods (implemented in TerminalDispatch) should call (new) methods on ITerminalApi, implemented in Terminal.
  
  
  
  • The Terminal should probably stash whatever the progress bar state is inside itself, and expose methods for querying that state.
  
  
• [ ] These Terminal methods should probably trigger some sort of callback, that TermControl can listen for.
• [ ] TermControl's callback should merely raise an event that can be used to bubble the event up to TerminalPage.
• [ ] TerminalPage should add listeners to TermControls as they're created, and use those listeners to bubble it's own progress event that the AppHost can listen for.
  
  
  
  • Note that the page should only bubble the event of the currently focused tab/pane, and when the tab/pane focus changes, it should raise a new event to match the state of the focused control. (this is why we needed the "methods for querying that state" on Terminal). This would be much like the events we have for the tab title currently (though maybe a little simpler).
  
  
• [ ] AppHost should listen for events from the TerminalPage to know when it should update the progress bar on the title. AppHost is actually the object that knows about the HWND that's hosting the terminal.

This is kinda the bottom-up approach I'd take to implementing this myself for the Terminal. I'd probably want to start by looking at the last bullet point, actually. That way I'd know what shape the event that's going to get bubbled all the way through all these layers would need. I'd reckon that will line up pretty close with the VT sequence we'll be parsing at the start.

This would probably be a lot easier if you just wanted to implement it for conhost. Not nearly as much bubbling (but not _no_ bubbling).

The events for setting the title will be really similar actually. There's a bit of extra logic for handling the title, depending on if the user has suppressApplicationTitle or any of those related settings, but you could probably ignore that for now.

[j4james]

We should probably also make sure that we support the TBPF_INDETERMINATE state - for something like our own bcz.cmd, where we don't know how long the operation will take.

Note that ConEmu does already support the indeterminate state, by setting the _st_ parameter to 3. It's just not documented.

[mintty]

Why would the "green" and "red" options be supported but not the "yellow"?
Since OSC sequence also support text parameters, this could be done in a compatible way like:
ESC ] 9 ; 4 ; yellow ; pr ST

[j4james]

Why would the "green" and "red" options be supported but not the "yellow"?

The best place to ask this would be on on the ConEmu repo.

[zadjii-msft]

I totally forgot that there was also a yellow state to the taskbar as well. I think we should probably just make that st=4, for consistency with the other possible values for that parameter. That would map to the TBPF_PAUSED state

[j4james]

I think we should probably just make that st=4, for consistency with the other possible values for that parameter. That would map to the TBPF_PAUSED state

ConEmu already uses _st_ 4 and 5 for something else (not exactly sure what), so it would need to be something outside that range. But if we want to extend this, I strongly recommend discussing it with the ConEmu devs first, since it's their sequence we're adopting. If they aren't interested, we can still choose to come up with the extension ourselves, but I think it's only polite to let them have the first crack at it.

[zadjii-msft]

Summoning @maximus5 - Could you help enlighten us what ESC ] 9 ; 4 ; 4 and ESC ] 9 ; 4 ; 5 do in ConEmu, and help weigh in on what sequence should be used for the TBPF_PAUSED state (maybe ESC ] 9 ; 4 ; 6 if 4 and 5 are already something else)

[Maximus5]

Sure.
Both ESC ] 9 ; 4 ; 4 ST and ESC ] 9 ; 4 ; 5 ST sequences are free for the moment. (There were some plans which were never implemented).
The ESC ] 9 ; 4 ; 4 ST for TBPF_PAUSED looks good.

[zadjii-msft]

Thanks for the quick reply @Maximus5!