* Add to WorkingCopyCapabilities enum to reflect usage.
The capabilities field was being used with a value of 0 in a few places that implemented the IWorkingCopy interface. This inconsistency wasn't picked up by the compiler because the value in the enum was specified as `1 << 1` and not as `2`. This changes the value to be specified as `2` (for better type checking) and makes the 0 to use the new enum value.
* some polish on top
Co-authored-by: Maksym Taran <maksym.taran@gmail.com>
Co-authored-by: Benjamin Pasero <benjpas@microsoft.com>
Add proposed webview view API
For #46585
This adds a new `WebviewView` proposed api to VS Code that lets webview be used inside views. Webview views can be contributed using a contribution point such as :
```json
"views": {
"explorer": [
{
"type": "webview",
"id": "cats.cat",
"name": "Cats",
"visibility": "visible"
}
]
},
```
* Use proper activation event
* Transparent background
* Fix resize observer
* Adding documentation
* Move webview view to new directory under workbench
* Remove resolver
By moving the webviews view into their own fodler, I was able to avoid the cycle the resolver was originally introduced for
* Use enum in more places
* Hook up title and visible properties for webview views
* Remove test view
* Prefer Thenable
* Add unknown view type error to collector
This removes the initial notebook renderer API and keeps the 'pure'
renderer API described in #102644 and hacked-in previously.
Remaining work in this area, in no particular order:
- Add messaging context to postMessage as requested by Don (API proposal TBA)
- Cleanups around how state is managed internally in the backLayerWebView
- Deprecate the renderer `viewType` in favor of calling it the `id` or `rendererId`
Q: I kept around some of the "transform" functions since the mime type
picking happens there, not sure if there's a better place for this
to happen now, or whether these methods should simply be renamed.