Git status representation in the explorer viewlet implemented

[kisstkondoros]

Resolves #5866

[mention-bot]

By analyzing the blame information on this pull request, we identified @egamma and @bpasero to be potential reviewers

[bpasero]

Unfortunately I cannot accept this PR as such because it introduces a dependency from files land to git land. Logically files land should not be aware of git land but rather we should have extension points that allow us to modify the colors and possibly icons in the explorer from the outside. This would maybe also allow extensions to do this.

[kisstkondoros]

@bpasero If I got you right then we could do the following:
The FileRenderers get's a registry whose items can be processed in renderContents method.
This way there is no thight coupling, and this registry could be used maybe even from extensions.

the interface in use could be e.g.

interface FileRendererDecorator {
    decorateItem(tree: ITree, stat: FileStat, explorerItemLabel: HTMLElement) : void
}

perhaps this could even be used to support icons in the explorer.

[bpasero]

Yes, we need a registry where other components can participate in decorating explorer items. I actually think this should be generic enough for any tree we have and not just the explorer. Trees can then opt in to decide if they want to participate in decorations or not and the explorer could be the first one of those.

Have not yet thought about how the API (both internal and possibly external could look like). Maybe we open a discussion issue first?

[kisstkondoros]

@bpasero Good idea, please open a discussion issue when you have some time 👍

[kisstkondoros]

@bpasero I've updated the implementation according to what we have discussed, please have a look

[bpasero]

Thanks, since it is currently endgame, expect no reply until July milestone 👍

[kisstkondoros]

Some more related issues: #1394, #211, #4837, #1086, #178

[bpasero]

Adding @joaomoreno because this PR touches a lot in tree and git land.

[johanneslamers]

Oh yes please!! As soon as possible!!

[joaomoreno]

I think there are a few shortcomings with the current approach:

• Augmenting the tree's API is unnecessary. The tree provides a structure around HTML elements. The contents of each tree row, after render is called, are not the tree's responsibility no more. So, adding a decorator API at that layer is wrong.
• There are also layer breakers such as git knowing about OpenEditor and FileStat, or worse, knowing about how these are rendered: row.element.querySelector('.open-editor .name').

Given that I am tempted to close this issue. It needs proper planning, architecture and most of all: time.