Support indeterminate progress notifications #10945
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What it does
progress
notification type ifshowProgress()
is used instead of overwriting it withinfo
progress
notification type through to view to make it aware that this is a progress without having to specify a value for the progressprogress
but no numericprogress
value is specifiedinfo
icon by default in view forprogress
notifications (this was implicitly done before too because we overwrote the notification type withinfo
if the client didn't specify oneFixes #10944
How to test
Use the added sample commands "Sample Command With Indeterminate Progress Message" and "Sample Command With Progress Message". See also their handler implementation in
sample-menu-contribution.ts
, in particular how one reports no progress (indeterminate) and the other one does.With progress reporting:
Without progress reporting:
Other Observations
messageService.showProgress({ type: MessageType.Error, ...})
even though the argument typeProgressMessage
dictates the optionaltype
parameter to be of typeMessageType.Progress
. If clients still set another type, such asMessageType.Error
this would affect the icon being shown in the notification. This PR doesn't change that behavior, but we only show an indeterminate progress, if the message type isMessageType.Progress
.{ done: 0, total: 100 }
is equal to specifying no progress, which is after this PRindeterminate
. This might be surprising, but I felt it is fine as no progress bar would otherwise be visible anyway. This is because of the way how a progress update is handled inNotificationManager#toPlainProgress()
.NotificationManager#reportProgress(...)
falls back to previous progress message, if the new one is undefined. I guess this behavior is fine, because otherwise clients would be forced to always provide awork
in their update, even if they just want to set a new message.Review checklist
Reminder for reviewers