- 16 10月, 2019 2 次提交
-
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
Instead pass over the extension when resolving the extension itself
-
- 11 10月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
This matchs the naming of a few other services we have
-
- 04 10月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
Fixes #81889 Using `.matches` can cause a custom editor to match all custom editors for that resource. Use a strict compare instead.
-
- 02 10月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
Inputs should not need to know about extensions
-
- 27 9月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
Split out from #77131 The current webview editor api is very procedural. This model has some problems when it comes to supporting editing resources, but actually does make a lot of sense for webviews that aren't backed by real file system resources. For example, if you have a webview that edits some document in the cloud, you should not be required to implement a custom file system provider just to enable basic saving. This change moves the `onWillSave` and `webviewEditorState` properties back onto `WebviewPanel` instead of keeping them specific to `WebviewEditor`. The save implementation does not fully work yet, as the will require #81521
-
- 26 9月, 2019 2 次提交
-
-
由 Matt Bierner 提交于
This fixes an issue where webviews for custom editors did not have any associated extension information, which caused them try reading `file:` uri resources instead of remote uri resources
-
由 Matt Bierner 提交于
-
- 24 9月, 2019 2 次提交
-
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
Fixes #80184 Don't rely on a state being set as well
-
- 20 9月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
-
- 16 9月, 2019 1 次提交
-
-
由 Benjamin Pasero 提交于
-
- 14 9月, 2019 4 次提交
-
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
- 13 9月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
#77131 This information will be used to show the dirty indicator and also enable/disable save
-
- 12 9月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
-
- 11 9月, 2019 2 次提交
-
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
* Custom Editor exploration For #77131 Adds a prototype of custom editors contributed by extensions. This change does the following: - Introduces a new contribution point for the declarative parts of a custom editor - Adds API for registering a webview editor provider. This lets VS Code decided when to create a webview editor - Adds an `openWith` command that lets you select which editor to use to open a resource from the file explorer - Adds a setting that lets you say that you always want to use a custom editor for a given file extension - Hooks up auto opening of a custom editor when opening a file from quick open or explorer - Adds a new extension that contributes a custom image preview for png and jpg files Still needs a lot of UX work and testing. We are also going to explore a more generic "open handler" based approach for supporting custom editors Revert * Re-use existing custom editor if one is already open * Don't re-create custom editor webview when clicking on already visible custom editor * Move customEditorInput to own file * First draft of serializing custom editor inputs * Use glob patterns instead of simple file extensions for matching custom resoruces for custom editors * Add descriptions * Try opening standard editor while prompting for custom editor * Make sure we hide image status on dispose * Make sure we restore editor group too * Use glob patterns for workbench.editor.custom * Allow users to configure custom editors for additional file types * Use filename glob instead of glob on full resource path * Adding placeholder for prompt open with * Add enableByDefault setting for editor contributions * Enable custom editors by default and add `discretion` enum Changes `enableByDefault` boolean to a `discretion` enum. This should give more flexibility if we want other options (such as forcing a given custom editor to always be used even if there are other default ones) * Allow custom editors to specify both a scheme and filenamePattern they are active for * Rework custom editor setting * Don't allow custom editors to be enabled for all resources by a config mistake * Replace built-in image editor with one from extension * Adding reopen with command * Improve comment * Remove commented code * Localize package.json and remove image * Remove extra lib setting from tsconfig
-
- 27 8月, 2019 2 次提交
-
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
Fixes #79647
-
- 22 8月, 2019 2 次提交
-
-
由 Matt Bierner 提交于
strict null checks should prevent calling this function with undefined
-
由 Matt Bierner 提交于
This value should always be a number
-
- 21 8月, 2019 6 次提交
-
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
Previously we fired one event per webview. This change switches to fire on event per update
-
由 Matt Bierner 提交于
This page should never contain anything except text
-
由 Matt Bierner 提交于
The webviews should always be accessible through the inputs
-
由 Matt Bierner 提交于
Fixes #79492 Simplifies view state management logic in `mainThreadWebviews` to: * Not be stateful * Handle cases where a webview's view state changes through a more complex means (see #79492 for an example of this)
-
- 20 8月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
Fixes #79424 This file depends on dom api so it should live in browser instead of common
-
- 15 8月, 2019 2 次提交
-
-
由 Sandeep Somavarapu 提交于
-
由 Sandeep Somavarapu 提交于
-
- 23 7月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
-
- 18 7月, 2019 4 次提交
-
-
由 Matt Bierner 提交于
This change attempts to do the following: - Encapsult most of the logic for handling the webviews used for webview editors into a new WebviewEditorOverlay class - Greatly simplify WebviewEditorInput and make it take a webview when it is created - Move the webview creation logic up into the webviewEditorService instead of having it be inside the webviewEditor class itself This aim of these changes is to make it possible to re-use more of the webview logic for custom editors
-
由 Matt Bierner 提交于
We previously used nested states to store some additional metadata alongside the real webview state. This is overly complicated. This change switches us to using a single top level state field, while also adding some code to handle migration from the old state structure
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
- 13 7月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
Fixes #77132 Add support for loading webviews from and endpoint that looks like: ``` https://{{uuid}}.contoso.com/path/to/some/commit/index.html ``` This lets us serve each webview from a seperate origin
-
- 11 7月, 2019 1 次提交
-
-
由 Matt Bierner 提交于
This should no longer be required
-