-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Conversation
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this 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.
Co-authored-by: JohnMcPMS <johnmcp@microsoft.com>
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. |
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... |
There was a problem hiding this comment.
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.
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this 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.
@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. |
Cool 👍
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. :) |
The only part of the build that failed was publishing the test result artifacts, so I'm going to go ahead and merge. |
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, |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. 😁
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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! 😁)
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
andProgressBar
classes, as opposed to creating a new class derived fromProgressVisualizerBase
. The latter should work easily for determinate progress but for the spinner case,IndefiniteSpinner
contains some logic withSleep
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