Support proposed DecorationProvider api on custom views

[eamodio]

Currently it looks like the DecorationProvider api, only applies to the explorer file tree. Can this be expanded to apply to custom view trees as well?

Maybe expand to include an optional viewId

registerDecorationProvider(provider: DecorationProvider, viewId?: string): Disposable

The DecorationProvider.provideDecoration will also need to be updated to support TreeItem (or the item element itself?)

provideDecoration(uriOrTreeItem: Uri | TreeItem, token: CancellationToken): ProviderResult<DecorationData>;

Also while its probably not ideal, I did wonder if setting a resourceUri on a TreeItem would trigger the decoration, but it doesn't either.

/cc @sandy081

[jrieken]

Yes, plan is to make the DecorationProvider api public. However, but its nature it decorates URIs wherever they show. Things we should do IMO

• allow tree view item to be decorated
• make the decoration provider api general available

[eamodio]

Hrm, showing decorations where ever a URI is seems like it could be very undesirable in many cases. If I have a custom view that I want to decorate items with (that represent files) and my decorations would now show everywhere they would now conflict with the scm/git decorations and vice versa. If that was still the desired behavior, it would be nice if the custom view (or custom view item) could opt-in (or out) of global decorations.

Will there be a way to decorate custom tree items then (that would not affect anything outside a specific tree)? Maybe those decorations could be applied directly on the custom tree item itself (i.e. props or something provided to the TreeItem)?

For example, I am definitely looking for ways of bolding, italicising, coloring, badging tree items for the CodeStream extension I am currently working on.

[sandy081]

I see there are two kinds of requests here from a custom view perspective.

1. Apply the file decorations also to custom view if it is based on URIs. This can be opted out by user using settings just like how it is now.
2. Allow extensions to decorate custom view items.

First one looks sensible but there are no plans yet to support second one.

[eamodio]

I think so, but #1 is more nuanced imo.

I honestly was more thinking about #1 as a way to get #2 -- use "custom" uris (foo://whatever) to attach to the resourceUri and then use the DecorationProvider to only respond to those custom uris. Which would in theory provide decorations for the custom view. But the flip side to this, is that would make all of the explorer decorations automatically apply to all custom views (if they were using real file uris) and that may or may not be desirable.

Maybe an alternative would be to add a way (property or something) on the custom view to opt-out of decorations if they wanted.

[d-akara]

2. Allow extension to decorate custom view items

This is a very needed feature for tree views that I'm creating. It places significant impediments on the readability of the data presented when there are lots of attributes.

[sandy081]

Adding to July as stretch item.

[sandy081]

Added support for resource based decorations in custom views. Decorations are shown automatically when a resource uri is provided and there are decorations for that resource. These can be controlled by user using the existing following settings

explorer.decorations.colors
explorer.decorations.badges

If the extension providing custom view does not want the decorations to be shown, then it should not provide resource uri. This is much analogous to theme icons derived from resources.

Created a separate feature request #54938 to make decoration provider api public.