SCMResourceDecorations ambiguity

[chrmarti]

• VSCode Version: Code - Insiders 1.11.0-insider (6ae8c15, 2017-03-29T08:21:59.122Z)
• OS Version: Linux x64 3.13.0-108-generic
• Extensions: none

---

Testing #23311

SCMResourceDecorations has an iconPath and at the same time dark and light, all can be specified in the same decoration, but only dark/light will be used. An alternative that only allows one of the two options at once would be:

type SCMThemableDecoration<T> = T | { dark?: T; light?: T; };

interface SCMResourceDecorations {
    strikeThrough?: boolean;
    iconPath?: SCMThemableDecoration<string | Uri>;
}

let a: SCMResourceDecorations = {
    iconPath: 'foo'
}

let b: SCMResourceDecorations = {
    iconPath: {
        dark: 'bar',
        light: 'baz'
    }
}

[joaomoreno]

Interesting. I went with the same approach as for the editor decoration api.

Thoughts @jrieken ?

[jrieken]

@alexandrudima and @aeschli know the reasoning behind the editor decoration API. As usual I am in for consistence. Also the editor inherit and overwrite approach has the benefit of not needing to repeat equal values. That will come into play once there are more values, but then it allows you define the defaults in the literal and then you only have specialisations/overrides in the light/dark part

[jrieken]

Tho what we could consider is to always use the Uri for the path. I know it's sort of legacy that the editor decoration api supports both and there was ambiguity if strings mean url or file path (see #12111 (comment))

[joaomoreno]

As per last comment: #23648

[alexdima]

The editor decorations allow to specify different values for dark/light at decoration creation time because we want to be able to switch themes without deleting all decorations or needing to go back to extensions and ask them to update the decorations to match the new theme. i.e. decorations are set with both light/dark options and we can easily flip between the light/dark options when the theme changes on the UI thread, without pinging extensions and without loosing decorations.

[joaomoreno]

I would go for consistency here and keep the same API.