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

Implement VT-based progress reporting #883

Merged
merged 4 commits into from
Apr 22, 2021

Conversation

chausner
Copy link
Contributor

@chausner chausner commented Apr 21, 2021

This implements #869: if VT is enabled, OSC 9;4 sequences are printed in addition to the existing progress spinner and progress bar.

Whenever an indefinite spinner is printed, a corresponding OSC sequence with state "Indeterminate" is output. When the spinner is hidden, an OSC sequence to clear the progress is written. Analogously, OSC sequences for showing/updating/hiding determinate progress are printed.

I noticed that the implementation of the progress OSC sequences in Windows Terminal does not exactly match the implementation in ConEmu. In particular, ConEmu allows the progress value to be left out (e.g. to switch progress states without having to specify the current progress value again) but Windows Terminal does not recognize these sequences at the moment. It is not really an issue at all, there are just a couple of lines with workaround logic.

I added the new logic to the existing IndefiniteSpinner and ProgressBar classes, as opposed to creating a new class derived from ProgressVisualizerBase. The latter should work easily for determinate progress but for the spinner case, IndefiniteSpinner contains some logic with Sleep that would have to be duplicated if we want to separate the VT-logic into its own class, which is probably not so nice.

@JohnMcPMS mentioned potential issues with clearing the progress when a user forces a process exit by hitting Ctrl+C twice. I am able to reproduce this issue by running winget source update and quickly hitting Ctrl+C twice. In this case, the progress indicator in the taskbar is indeed not cleared but there are also other issues like the console foreground color not getting reset (the spinner uses a different color). So any fix for this issue should ideally not only reset the taskbar progress bar but also any other terminal state like colors.

Microsoft Reviewers: Open in CodeFlow

@chausner chausner requested a review from a team as a code owner April 21, 2021 22:57
@yao-msft
Copy link
Contributor

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Member

@JohnMcPMS JohnMcPMS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was promised this would take a week 😉

This is exactly what I would have done, and I think will work well. I do wonder though if we should actually set the indeterminate state as soon as we hit anything with progress, then not disable it until we exit. By which I mean, rather than None right now, we would write Indeterminate (or nothing if we already know that is the state we are in), and have set a flag somewhere that on destruction/exit we write None to close it out.

I'm not sure what it looks like right now when it flips back and forth, or maybe those happen so fast that it isn't really noticeable. That might just need to be something we give a chance and see if we need to improve on it.

src/AppInstallerCLICore/VTSupport.h Outdated Show resolved Hide resolved
src/AppInstallerCLICore/VTSupport.cpp Outdated Show resolved Hide resolved
src/AppInstallerCLICore/VTSupport.h Outdated Show resolved Hide resolved
src/AppInstallerCLICore/VTSupport.cpp Show resolved Hide resolved
@denelon denelon linked an issue Apr 22, 2021 that may be closed by this pull request
chausner and others added 2 commits April 22, 2021 18:36
@chausner
Copy link
Contributor Author

I do wonder though if we should actually set the indeterminate state as soon as we hit anything with progress, then not disable it until we exit. By which I mean, rather than None right now, we would write Indeterminate (or nothing if we already know that is the state we are in), and have set a flag somewhere that on destruction/exit we write None to close it out.

I'm not sure what it looks like right now when it flips back and forth, or maybe those happen so fast that it isn't really noticeable. That might just need to be something we give a chance and see if we need to improve on it.

Good point. It seems it can look slightly distracting when it switches states multiple times in quick succession but most people probably wouldn't notice. Your proposal of always staying in the Indeterminate state would probably work, it just makes the code slightly less nice or might lead to issues later on (suppose winget adds some form of user interaction/confirmation in the future, if there was a spinner displayed before, it would continuously show the Intermediate state while waiting for user input. That would probably feel distracting.).

So I suggest us to get a bit experience first how the current implementation feels in practice, then can decide if we need to tweak it or if it is fine as it is.

@denelon
Copy link
Contributor

denelon commented Apr 22, 2021

I'll defer to @JohnMcPMS on the initial implementation. I'd be happy to solicit feedback from the community, and I can likely get @cinnamon-msft to help get feedback from Windows Terminal users. Just let me know what scenarios we want to ask for the community to test.

// Multi-terabyate installers should be fairly rare for the foreseeable future...
// Multi-terabyte installers should be fairly rare for the foreseeable future...
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. Thanks for catching this. Initial spell-checking passes are best effort, and a goal is for people to incrementally improve.

@JohnMcPMS
Copy link
Member

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Member

@JohnMcPMS JohnMcPMS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I look forward to trying it out.

@denelon
Copy link
Contributor

denelon commented Apr 22, 2021

@chausner I'm hoping to get this out in a build next week. I'll tweet about it as well. Would you like me to @mention you or not?

If you would just let me know your Twitter handle.

@chausner
Copy link
Contributor Author

@chausner I'm hoping to get this out in a build next week. I'll tweet about it as well.

Cool 👍

If you would just let me know your Twitter handle.

Thanks but I am not on Twitter. But feel free to mention my GitHub name in the next blog post in case you mention the feature there. :)

@JohnMcPMS
Copy link
Member

The only part of the build that failed was publishing the test result artifacts, so I'm going to go ahead and merge.

@JohnMcPMS JohnMcPMS merged commit 43e70fa into microsoft:master Apr 22, 2021
case State::Normal:
case State::Error:
case State::Paused:
// Windows Terminal does not support switching progress states without also setting a progress value at the same time,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somebody shoulda filed this bug on us! 😉


THROW_HR_IF(E_BOUNDS, percentage.has_value() && percentage > 100u);

// Workaround some quirks in the Windows Terminal implementation of the progress OSC sequence
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Y'all, we work at the same company. If I keep finding "quirk for Windows Terminal" comments I'm gonna have to glare at you from across the lunch room. 😁

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will keep that in mind @DHowett , although this one is more of an external report through us, so maybe we can still be friends?

Copy link
Contributor Author

@chausner chausner Apr 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am to blame for writing that mean comment, sorry. 😁 I wanted to check whether this was a known issue/limitation (I think I saw an issue with some follow-up tasks related to the initial implementation in Windows Terminal) but forgot about it in the end.

I see you haven't yet created an issue report so let me do it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created an issue for this in the Windows Terminal repo: microsoft/terminal#9960

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a ton!

(sorry -- my joke probably came across very poorly over the medium of text. Thanks for being understanding! 😁)

@chausner chausner deleted the vt-progress-bar branch April 26, 2021 18:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide Taskbar progress indicator in Terminal
6 participants