Allow extensions to contribute custom icons for webview panels #49657
Conversation
Fixes microsoft#48864 Adds a new top level `webview` contribution point. Use this new contribution point to contribute the declarative part of a webviews, such as icons
| @@ -26,6 +26,15 @@ | |||
| "onView:markdown.preview" | |||
| ], | |||
| "contributes": { | |||
| "webviews": [ | |||
There was a problem hiding this comment.
I initially tried putting this new point under views, but now that we support custom view containers it does not seem like a great fit there
There was a problem hiding this comment.
Not sure what you mean by 'custom view containers'?
There was a problem hiding this comment.
The custom activity bar sections that we added last iteration. I see two concerns with reusing views for webview contributions:
- Webview contributions would not have the same properties as the other items in
views. - As we now support contributing a custom view container with any name, there's nothing to stop someone from creating a view container named
webviews. Pretty unlikely this will be a real problem so the first point is the main concern
There was a problem hiding this comment.
If it has to be merged into the views extension point, then editor is the right location for web views instead of webviews. IMO Web view and Tree view are types of views. I see that at present Tree views and Web views do not have common schema, for e.g. Tree views do not have icons where as web views do. We can have either schema by type or schema by location depends on how they emerge in future. Looking at present scenario, it looks to me that the location drives the properties. I mean, views registered in activity bar containers do not need icons but icons are needed for views registered under editor. In future, if we want to be flexible in moving views across, then all views can define icons optionally. Not sure what is viewType property in web views. May be this can be used to differentiate tree views vs web views?
I think the second point you mentioned is a valid concern. May be we should think of restricting some default locations like editor or panel.
Or other approach would be to use viewsContainersextension point? Say, introduce a new locationeditor` and create a new view container for web views. It means a view container inside editor can contain multiple views(web or tree).
|
Maybe @sandy081 can add his 2 cents because he has most experience with those things |
|
If it has to be merged into the views extension point, then editor is the right location for web views instead of webviews. IMO Web view and Tree view are types of views. I see that at present Tree views and Web views do not have common schema, for e.g. Tree views do not have icons where as web views do. We can have either schema by type or schema by location depends on how they emerge in future. Looking at present scenario, it looks to me that the location drives the properties. I mean, views registered in activity bar containers do not need icons but icons are needed for views registered under editor. In future, if we want to be flexible in moving views across, then all views can define icons optionally. Not sure what is viewType property in web views. May be this can be used to differentiate tree views vs web views? I think the second point you mentioned is a valid concern. May be we should think of restricting some default locations like editor or panel. Or other approach would be to use viewsContainersextension point? Say, introduce a new locationeditor` and create a new view container for web views. It means a view container inside editor can contain multiple views(web or tree). |
Allows webviews to provide icons used in UI. Adds a new `WebviewPanel.iconPath` property for this. Replaces the static contribution approach from microsoft#49657 Fixes microsoft#48864
|
Superseded by #54912 |
Fixes #48864
Adds a new top level
webviewcontribution point. Use this new contribution point to contribute icons to webviews declaratively