vscode.FileDecoration color overides gitDecoration color on folders, even when set to null

[jgphilpott]

Hi,

I have been using this extension to add colors, badges and tooltips to the folders and files in my repo. The extension uses vscode.FileDecoration to add a color, badge and tooltip to a given path. It works well except that it overrides gitDecoration colors (for added and modified files) even if I dont provide a color argument. The docs I linked indicate that the color argument is nullable so the behavior I would expect is that if no color is provided the badge and tooltip will be applied but the color will be unaffected. This however is not the case, it seems a default color is used if none is provided.

This is frustrating because it makes it difficult to see what files have been added or modified, especially if they are within a collapsed folder. Essentially I want to be able to use the badge and tooltip features of vscode.FileDecoration without affecting the color. It would be great if this functionality could be added or if an alternative solution/workaround is available let me know. Thanks!

Jacob

[jrieken]

It's not really defined, today extension decorations get sorted with the same weight and the first (which is arbitrary) defines the color - even if that's falsy.

I am not 100% sure but I believe we can relax that rule and take the first defined color.

[jgphilpott]

Cool, it sounds logical to me that falsy values should be ignored and the first explicitly defined color takes precedence. Then I can use the FileDecoration class without providing a color argument and it shouldn't override the git colors :)

[jgphilpott]

Alternatively, could there be a way to set the weight/priority of a decoration? It would be nice to use color decorations but have the git colors override my personal colors rather than the other way around.

[jrieken]

could there be a way to set the weight/priority of a decoration

We generally dislike explicit weights/prios because an unfair player can use high values and even a fair player wouldn't know what values to use because it isn't know what values are used by other extensions. I believe "falsy yields the floor" is the better model here

[jgphilpott]

Okay, I'm good with the "falsy yields the floor" solution. Just to clarify though I was thinking the weights/prios would be set on an individual level, not by the extension creators. Like somewhere in my settings.json I could have an array that ranks my extension priorities. Everyone could have their own unique set of weights.

[jgphilpott]

Any update on this @jrieken? I would be happy to help if you could point me in the general direction. I've just never worked on this repo before so i'm a little clueless where to even start.

[pablotecheraa]

Hi, I have the same problem with an extension I'm creating. If I just add tooltips to the extension, it still overwrites all the Git colors.

Before

After

The only colors visible in the images are for problems or warnings, but the rest is all white. The expectation would be that if the extensions haven't set a color, the existing ones shouldn't be replaced.

[jgphilpott]

@pablotecheraa I don't know why your comment got marked as spam but I appreciate you demonstrating that this is a common issue and the current behaviour is not what's expected. I am not alone! 😁👍