Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to open a custom file viewer window without opening the default one #12176

Closed
fwang2002 opened this issue Sep 17, 2016 · 16 comments
Closed
Assignees
Labels
api custom-editors Custom editor API (webview based editors) *duplicate Issue identified as a duplicate of another issue(s) feature-request Request for new features or functionality workbench-editors Managing of editor widgets in workbench window
Milestone

Comments

@fwang2002
Copy link

I want to implement an extension to display a graphical presentation for a binary file. I have had a look at markdown extension. But it displays the customized preview window with the default editor window side by side. So I want to know:

  1. Is there a method to only open the preview window (customized) without opening the default editor window.
  2. Can the default editor window be embedded in a customized window
    It will be great if extension developers can freely compose their customized window with the internal VSCode views such as Editor, Tab, etc.
@jrieken jrieken added the feature-request Request for new features or functionality label Sep 19, 2016
@jrieken jrieken removed their assignment Sep 19, 2016
@jrieken jrieken added the ux User experience issues label Sep 19, 2016
@yzhang-gh
Copy link
Contributor

yzhang-gh commented May 14, 2017

By now, there are several extensions to add support to more file types, (updated: 25 March, 2019)

Extension #installs
Excel viewer 379,793
PDF viewer 136,801
NuGet NuPkg Viewer 8,786

We can see the great needs of this feature. But all of those preview extensions have a limitation.
If we open a .pdf or .xlsx file by directly clicking on the file in the vscode file explorer (just like how we open a text file), vscode will complain it's a binary file and won't open it.
To preview the file, we need to right-click the file and select 'open preview'.

So, besides registerTextDocumentContentProvider, having another command such as registerFileContentProvider would be great.

@chengs
Copy link

chengs commented May 31, 2017

Support @neilsustc.

I tried to improve the pdf previewer and found that it was impossible because of lacking related extension hooks.

Indeed, vscode already has built-in schemes for reading images and videos in src/vs/base/browser/ui/resourceviewer/resourceViewer.ts. It would be great to design a similar extension hook.

@chengs
Copy link

chengs commented May 31, 2017

Ref to #10821

@yzhang-gh
Copy link
Contributor

I think we should guide more people to this issue and give more 👍 on it.

It was after I tried many keywords that I finally found this issue.

@bpasero bpasero added workbench workbench-editors Managing of editor widgets in workbench window and removed workbench labels Nov 11, 2017
@bpasero bpasero changed the title open a custom file viewer window without opening the default one Allow to open a custom file viewer window without opening the default one Nov 17, 2017
@bpasero bpasero added api and removed ux User experience issues labels Nov 17, 2017
@dschaefer
Copy link

There was good discussion on #5604.

The only addition I have is to enable these editors to be actual editors. The main item there is to have access to the EditorInput so we can set the dirty bit and such.

@dprandle
Copy link

It would be great to be able to assign certain file types external editors. There is no reason that I shouldn't be able to open a *.ui (Qt UI file) in vscode an have Qt Designer open up externally instead. This was very easy to do in emacs.

@dschaefer
Copy link

@dprandle I imagine that could be accomplished by being able to assign an "open" command for files of a given language with the Uri of the file to open passed as an argument. I think that would meet most people's needs.

@TomasHubelbauer
Copy link
Contributor

I ran into this, too. In my case I'd like to be able to hook onto a click on a video file and instead of it's editor display a read-only view preview (by supplying a HTML page with a video element in it).

I think at some point it would be super cool to have edit-mode for binary files (and possible custom binary editors within VS Code), but from my PoV even the ability to add read-only substitute views for particular binary files would be very helpful.

It would at least enable the Excel and PDF extensions (and the other ones like HexDump) to not have to rely on a right-click menu item. And it would enable my extension. I think if the hook handler was allowed to return null or undefined it could also enable opening the external editor for some file types (like Qt Designer).

@dschaefer
Copy link

What I'm seeing at Eclipse is a continuing move of advance tooling into the cloud, or at least attempts to. To make that happen they are building advanced editors using HTML5 that could easily run in a webview. I'm thinking of things like Eclipse Sirrius. Also, looking at Qt's new UI Designer which imports Photoshop artifacts, similar to what my friends at Crank Software do, it doesn't seem hard to build such a tool using SVG in a webview.

All that's missing is tying into the undo stack and "Save". And of course a whole bunch of things I'm probably over simplifying. But imagine how great VS Code could be if it could edit any file that a developer works with, not just text.

@dschaefer
Copy link

Digging through the code today trying to figure out how things are done. I have a webview panel that I'm using so took a look at how that got created. There's a WebviewEditorInput that doesn't implement any of the dirty/save methods of EditorInput. A naive guess would be to hook those up so that the extension would manage the content but trigger the EditorInput through the RPCProtocol.

The second question would then be how do you make it so you're webview gets created when opening the file. My initial feeling there would be to allow an extension to register an openCommand with a language. That command could then set up the webview. In the FileController.onLeftClick handler, it could check the language of the file and if it has a command, call it, and if not, call openEditor as it does now. Or maybe that happens inside openEditor. Somewhere before it tries to open a textEditor.

Just some thoughts. I'll play with these ideas and see how well the work out. Be great if someone from the vscode team can tell me I'm crazy or if they have a better idea :)

@dschaefer
Copy link

Undo/Redo is a bit more complicated. Looks like we'll need hooks in EditorOrNativeTextInputCommand which routes the command to the active/focused text editor. There's already a hook there to send the command to the document if it can't find the active editor. As the extension would be expected to manage the content, it would also have to have it's own undo/redo stack.

@dschaefer
Copy link

Bug #49325 is also discussing this topic.

@dschaefer
Copy link

LOL, raised a new issue hoping to spark new discussion around this and got dup'ed back. Anyway...

The vscode-pdf extension is another example of where this behavior is needed. They have a clever hack to close the text editor the moment they see it pop up and open their custom editor instead.

@yozlet
Copy link

yozlet commented Oct 18, 2019

The issue description raises two different questions, and so far (from what I can tell) all the discussion and implementation work has focused on the first: custom preview/editor panes for given file types. (See also the experimentation happening in #77131.)

I'm interested in the second question: how can extension authors embed a working code editor inside a custom (WebView or other) panel? By "working" I mean that it respects the user/session configuration for styling, extensions, undo/redo, etc.

There are already a couple of demonstrated uses for this, plus plenty more potential beyond:

  1. REPL/notebook editors, such as the Python extension's Jupyter interactive window. Because this is limited to the Extension API, it embeds the Monaco Editor and adds extra Python features. From what I can tell (and I may have this wrong), it means those features have to be implemented twice: once for VSCode, once for this customised Monaco widget.
  2. The Interactive Playground included with VSCode (linked from the Welcome screen). This seems to use the native CodeEditorWidget with a load of extra wrapping, and so inherits all the other configuration features.
  3. Playground-style tutorials for other languages, as part of a request to turn the Interactive Playground into a component for extensions.
  4. Display and edit sections of multiple documents in a single pane. This is why I'm interested in being able to embed editors at all: for editor panes in the style of Code Bubbles and Task Canvas. They make it much easier to work with the relevant sections of multiple files without needing to flip around tabs. The peek feature is a start, but it's only used for temporary editing of a single external document from a main document, and (from what I can tell) can't be invoked by extensions to the degree that would be useful here.

Is this issue a good place to discuss this feature, or should I open a new one?

@bpasero bpasero added this to the Backlog milestone Oct 24, 2019
@haneefdm
Copy link
Contributor

haneefdm commented Nov 1, 2019

An area of interest for me for a text editor is line numbers and contents to be virtualized that can still work with debuggers. I have two applications. Loading very large files (real or virtual). A memory window is an example where we never load the entire memory space but we pretend we do and load portions on-demand/scroll-actions. Another situation is disassembly where I would like the line numbers to be the address of an instruction and again contents are loaded sparsely and on-demand. Maybe there are other ways of doing this. I can use a WebView for memory window but I have no good workaround for the disassembly window that has to work with the debugger/breakpoints. See also Issue #34 which wants to do a hex dump of a binary file.

@bpasero bpasero added the custom-editors Custom editor API (webview based editors) label Jan 19, 2020
@mjbvz
Copy link
Collaborator

mjbvz commented Jan 23, 2020

This is covered by the custom editor api proposal: #77131

@mjbvz mjbvz closed this as completed Jan 23, 2020
@mjbvz mjbvz added the *duplicate Issue identified as a duplicate of another issue(s) label Jan 23, 2020
@vscodebot vscodebot bot locked and limited conversation to collaborators Mar 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api custom-editors Custom editor API (webview based editors) *duplicate Issue identified as a duplicate of another issue(s) feature-request Request for new features or functionality workbench-editors Managing of editor widgets in workbench window
Projects
None yet
Development

No branches or pull requests