core: add support for badge decorations

[kaiyue0329]

What it does

Fix: #4311
Fix: #4782

The following pull-request introduces a new 'widget-decoration' called badge which can be used to decorate tab-bars with a counter for display purposes. The decoration is useful as a means to notify end-users about an important feature such as the number of scm changes currently in the working tree, and/or the number of problem marker stats (infos, warnings and errors).

The pull-request also includes two new client contributions to make use of the new decoration for their respective views:

• scm: displays the number of changes in the working tree and is updated according to the provider.
• markers: displays the number of total problem marker stats for the workspace (infos, warnings, and errors).

Features:

• different display properties based on sidepanel and horizontal (ex: main area) layout
• improved display for large numbers (over 99 a badge of 99+ is displayed)
• supports theming

SCM:

Sidepanel	Horizontal

Problems:

Sidepanel	Horizontal

How to test

1. Make changes to a file in your local repository.
2. Open the Scm view (should see a badge that displays the number of git changes)
3. Discard the git changes and click the scm tab in the sidebar so that it has focus (the badge number should update)
4. Makes changes to a file in your local repository so that there is an error/warning
5. Open the Problems view (should see a badge that displays the total number of problems)

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

Signed-off-by: Kaiyue Pan [email protected]
Signed-off-by: vince-fugnitto [email protected]

[kaiyue0329]

@akosyakov Thank you for your previous review in #8148. @vince-fugnitto updated the code so that badge uses existing decorator-service and it is now a new type of decoration that other widgets can contribute to. It would be great if you can review this PR again.

[akosyakov]

code-wise it looks better, but problem badge shows wrong numbers:

[akosyakov]

code wise looks good to me

@vince-fugnitto Could you test please?

[vince-fugnitto]

The changes work well for me, the badges are correctly displayed in the sidepanel and horizontal areas:

scm

• verified that the number of working tree changes are correctly displayed
• verified that the number reflects new changes, discards
• verified using the builtin vscode git extension as well

problems

• verified that the problems-view correctly displays the number of problem statistics
• verified that the number is updated when new problem markers are created, or fixed

[Anasshahidd21]

The changes work pretty well for me.

1. Tested the scm. It correctly updates the badge count, and upon reverting changes it also decreases the counter.

2. Tested the problems view. It correctly identifies the value of the markers, and if any marker is removed it correctly updates it.

Tested on Windows.

[akosyakov]

it should happen always, not only in else

[paul-marechal]

There is a bug when doing the following:

• Move the SCM widget in such a way that it will be listed in a new tabbar.
• Move the SCM widget back anywhere, such as it will destroy the newly created tabbar.

From this point on, the badge won't update.

I came up with the following patch (Expand)

diff --git a/packages/core/src/browser/shell/tab-bar-decorator.ts b/packages/core/src/browser/shell/tab-bar-decorator.ts
index 41be55578..a1c6bf8ac 100644
--- a/packages/core/src/browser/shell/tab-bar-decorator.ts
+++ b/packages/core/src/browser/shell/tab-bar-decorator.ts
@@ -49,22 +49,17 @@ export class TabBarDecoratorService implements Disposable { 

     readonly onDidChangeDecorations = this.onDidChangeDecorationsEmitter.event;

-    protected readonly toDispose = new DisposableCollection();
-
     @inject(ContributionProvider) @named(TabBarDecorator)
     protected readonly contributions: ContributionProvider<TabBarDecorator>;   

     @postConstruct()
     protected init(): void {
-        const decorators = this.contributions.getContributions();
-        this.toDispose.pushAll(decorators.map(decorator =>
+        this.contributions.getContributions().map(decorator =>
             decorator.onDidChangeDecorations(this.fireDidChangeDecorations)
-        ));
+        );
     }

-    dispose(): void {
-        this.toDispose.dispose();
-    }
+    dispose(): void { }

     protected fireDidChangeDecorations = debounce(() => this.onDidChangeDecorationsEmitter.fire(undefined), 150);

Not sure why a singleton service was disposed but never re-initialized. This made me feel that it should not be disposed, but I don't know for sure.

[akosyakov]

Not sure why a singleton service was disposed but never re-initialized. This made me feel that it should not be disposed, but I don't know for sure.

It does not need to implement Disposable at all, that's true.

[vince-fugnitto]

The changes work well, the decoration continues to successfully listen to changes when the views are moved in the layout 👍

I'll merge the pull-request Monday if there are no objections.

[akosyakov]

@vince-fugnitto merging too?

[vince-fugnitto]

@vince-fugnitto merging too?

@akosyakov yes, are there are any objections?

[akosyakov]

@vince-fugnitto no, a follow up issue to add a badge for the debug view container would be nice to show how many sessions is running for instance