Allow product icon themes to override icons defined in contribute entries of an extension

[DeltaRazero]

Extensions can add contributes entries of which some accept custom icons. For example, take the vscode-bookmarks extensions, which defines a contribution endpoint for viewsContainers in its package.json:

"contributes": {
    "viewsContainers": {
        "activitybar": [
            {
                "id": "bookmarks",
                "title": "%bookmarks.activitybar.title%",
                "icon": "images/bookmark-activity-bar.svg"
            }
        ]
    },
}

This adds an entry to the activity bar with a provided custom icon to access the view. However, this icon cannot be overridden by a product icon theme.

Since product icon themes can provide new icons for the built-in codicons, of which icons are used for the 'standard' activity bar items, an extension's activity bar icon could be overridden to match the theme's style.

This use-case applies to all of the following, which allow an extension author to define custom icons:

• contributes.commands
• contributes.languages
• contributes.views
• contributes.viewsContainers

Food for thought is how to define the entrypoints for icons. I was thinking along the lines of adding a new key(s) to a product icon definition file "commands", "languages", "views", "viewsContainers". But then how would one reliably set the icons? Use extension ID in combination with the ID defined in one of those contribution entrypoints?

Would love to hear input from the VSCode team, and if if this use-case would be considered an in-scope issue,

[aeschli]

If an extension want's that their icon(s) is/are themable, it should not use a SVG but a product icon:

        "activitybar": [
            {
                "id": "bookmarks",
                "title": "%bookmarks.activitybar.title%",
                "icon": "${bookmark-view-icon}"
            }
        ]

Extensions can define new product icons with the icon contribution point

"contributes": {
  "icons": {
        "bookmark-view-icon": {
            "description": "View icon for the bookmarks view",
            "default": {
                "fontPath": "./bookmark-icons.woff",
                "fontCharacter": "\\E001"
            }
        }
    }
}

With that, any product icon can define a customized bookmark icon by defining a new icon for bookmark-view-icon.
The crux is of course that a product icon theme would have to know and cares about the bookmark extension. But if the extension is very popular that might happen. Also, a user might file an issue against the product icon theme requesting a extension the be better supported.
I don't see any other way.
I hope I property understood your request.

[DeltaRazero]

I don't see any other way. I hope I property understood your request.

Yes, the request was understood perfectly, so we're on the same line.

The crux is of course that a product icon theme would have to know and cares about the bookmark extension. But if the extension is very popular that might happen. Also, a user might file an issue against the product icon theme requesting a extension the be better supported

Yes, this of course will always be the case so there's no problem here.

Indeed the solution proposed in your comment is (and should be) the solution to the described problem. I made the assumption that VSCode's contribution point API was not capable of this, so you've cleared that up.

From this point onwards it's clearly the responsibility of extension authors (or those who provide pull requests) to change the hardcoded icons to product icons.

I could probably argue to deprecate providing a hardcoded icon in the contribution API but I think nobody is waiting on that. Perhaps updating the documentation on the contribution point API page to show/encourage using newly defined product icons would be a good idea though.

I don't need any further information and an acceptable solution is already possible. If no further discussion is warranted, the issue can be closed.

[aeschli]

Thanks for reply and feedback. You are right, it would be reasonable to deprecate SVG icons, they have other limitations too (e.g. we can't easily change the color). We haven't done that (yet) as contributing a icon is not that trivial as a font need to be created.

Closing the issue then