badges on custom activities added to activity bar by extensions

[elf-pavlik]

Previously mentioned by @eamodio in #43645 (comment) where @sandy081 asked to create separate issues for more specific features.

It would come helpful if extensions which create new activity in activity bar could also display a badge with a count. For example Gruntfuggly/todo-tree#22 has request to show number of TODO/FIXME found in the project.

[jrieken]

@elf-pavlik The progress indication will show the a tree view operation is in progress. And since the tree views is the only thing we support here I was assuming that what we have is good enough. What the scenario here? You update something but don't yet update the tree?

[Gruntfuggly]

A user defined counter would be useful. In my case the tree contains search results, so the counter would be a useful indication.

[sandy081]

@Gruntfuggly Not sure search results is a good example also the existing Search viewlet does not show the count.

[SergioTx]

I think it's different from search.

Search is a tab you open to search and close right after that, the information there is no longer needed.

In the Todo case, it's a useful information all the time, same as version control information, even with the tab closed.

[Gruntfuggly]

The source control view show a badge with a count of the number of items in the view - I think that's all that users are really asking for - they want to know how many items are in the view without needing to open it.

[sandy081]

What I meant the given example is not appealing. A badge being shown means it should be for a prominent reason like SCM outgoing changes. I see how it might be useful in case of Todo.

[gim-m]

I would love to get badge support too. For my use case, I have a custom activity bar item that shows the status of remote jobs. I would really like to show an indication that something is running without the user having to expand the view.

It could be handy to have the option for a count badge or a plain "dot" badge in cases where we know something is running, but we might not know the exact count.

Thanks!

[cnshenj]

I have another case: a task view using VSCode task API. If the custom activity bar icon can show a number to indicate how many tasks are running (especially long running background tasks), then a user doesn't need to expand the view if they just want to make a sure a task is not running.

[Gruntfuggly]

As an alternative to badges in the activity bar, how about allowing badges in the title bar of a view when it is collapsed? That way an icon could be displayed to indicate that something has changed in the view.

[spmeesseman]

+1 for this

[andrewbarnesweb]

Just installed the todo add on, and it would be awesome to see a count in these things without having to open it.

[nbransby]

Could we also consider a badge color properly and support for displaying without a number? I would like to show online/away/offline status in https://teamhub.dev/ as we do in IntelliJ (bottom left on first screenshot)

[mholtzhausen]

I am developing a team-centric activity and it would be very useful to have some means of indicating there are changes on that activity that a user would want to be notified about.

[Gruntfuggly]

There is a new API coming up allowing the title to be changed. Not quite badges, but it will at least allow something to be shown.

[luisjotapepe]

We are developing a static analysis extension that find issues in your code. It would be nice to denote in the icon how many issues are currently existing without having the user to move away from their editor screen to see this number. Just a thought.

[usernamehw]

It would be great to have progress state available; like SCM badge: https://code.visualstudio.com/api/ux-guidelines/views#views-with-progress

[alexr00]

@usernamehw we already support showing progress through the showProgress function:

vscode/src/vscode-dts/vscode.d.ts

Lines 9491 to 9511 in d8d25af

	/**
	* Show progress in the editor. Progress is shown while running the given callback
	* and while the promise it returned isn't resolved nor rejected. The location at which
	* progress should show (and other details) is defined via the passed {@linkcode ProgressOptions}.
	*
	* @param task A callback returning a promise. Progress state can be reported with
	* the provided {@link Progress}-object.
	*
	* To report discrete progress, use `increment` to indicate how much work has been completed. Each call with
	* a `increment` value will be summed up and reflected as overall progress until 100% is reached (a value of
	* e.g. `10` accounts for `10%` of work done).
	* Note that currently only `ProgressLocation.Notification` is capable of showing discrete progress.
	*
	* To monitor if the operation has been cancelled by the user, use the provided {@linkcode CancellationToken}.
	* Note that currently only `ProgressLocation.Notification` is supporting to show a cancel button to cancel the
	* long running operation.
	*
	* @return The thenable the task-callback returned.
	*/
	export function withProgress<R>(options: ProgressOptions, task: (progress: Progress<{ message?: string; increment?: number }>, token: CancellationToken) => Thenable<R>): Thenable<R>;

in ProgressOptions, you can specify a view id:

vscode/src/vscode-dts/vscode.d.ts

Lines 10592 to 10600 in d8d25af

	/**
	* Value-object describing where and how progress should show.
	*/
	export interface ProgressOptions {
	/**
	* The location at which progress should show.
	*/
	location: ProgressLocation | { viewId: string };

Does that work for you? We try not to have 2 ways to do the same thing in API, so we wouldn't want to use the badges API to show progress.

[usernamehw]

@alexr00 yeah, that's great. I didn't know about that. Maybe the UX guideline should include that other views also support showing progress. Now it's just says:

You can also show progress in the Source Control view if your view is inside of the SCM view container.

[alexr00]

Docs update in progress: microsoft/vscode-docs#5316

[matthewjamesadam]

Thanks for your help on this @alexr00 ! It's great to see the badge feature available in builds for extension developers to try out. I've been working against this and it seems to work pretty well.

Do you have an idea what the process and timeline look like for this to evolve from a proposed API to a stable API? The official documentation here doesn't make this clear: https://code.visualstudio.com/api/advanced-topics/using-proposed-api.

Should I be soliciting feedback at this point? I found some (possibly outdated?) documentation here that seems to indicate I should, but it's not clear exactly what I should be doing: https://github.com/Microsoft/vscode/wiki/Extension-API-process#api-proposal-implemented--feedback-requested

Thanks again!

[alexr00]

We don't usually have a set timeline for finalizing API. The best way to help us decide to finalize it is to try the API out and post any feedback you have in this issue. When more extension authors try out the API and provide feedback we gain confidence that the API is well designed and satisfies a real need.