Add some API to support GUI customization

[NoNameProvided]

VS Code is a great coding IDE, but developers love to customize their tools to make them feel like home and VS Code lacks those customization abilities.

I love the sublime material theme and I wanted to implement it in VS Code but as far as I can see it's not possible now because only the coding area is customizable. So in my opinion some improvement in ui customization would be welcomed by a lot of us. In the ideal word every pixel and element of VS Code should be customizable with extensions, but for start it would be enough to start with the following things:

• customization of the side panel (Improve the explorer view to match full VS design #123) - marked as done in Add file icons support in the explorer #211 (comment)
• adding support for custom tabs, the possibilities of the quick box is very limited (Allow extensions to add additional views #710) - marked as done in Allow extensions to add additional views #710 (comment)
• adding the ability to add and remove ui elements (e.g. a bottom panel for error listing like in Atom)

I have read about the approach followed by VS Code. So instead of allowing extensions to create custom ui elements, VS Code itself should provide some API for this, what allows to the developers to set the content, but the styling of the content should be based on the theme of VS Code.

So in a nutshell: VS Code core provide the bones and template of the ui elements, extension developers can set the content but not the style and theme developers can style the content.

[mohammedzamakhan]

👍

[joaomoreno]

@egamma @chrisdias fyi

[egamma]

see also #1231

[siegebell]

I wrote about this a bit in #272.

At the moment, you can write a custom UI by showing a markdown document in preview mode that contains an iframe to an HTML file that communicates with your extension via web sockets. So far, it has worked really well for me. It will get a bit easier when the virtual read-only document feature is released (#272). But it cannot integrate with the rest of the vscode UI and getting the right theme is tricky (you can access vscode's markdown css by recursively looking up the iframe parent's style sheet).

(For those interested, you can see the HTML view I wrote here and the code that connects the HTML view to vscode here).

But the response from @jrieken was:

the preview mechanism isn't designed to be a UI extension API. While you can render html and run scripts you should not go crazy in there.

So it's not clear to me whether this will remain a viable/supported solution in the future.

In particular, I am unsure whether the following comment,

The updating (when a document emits a change event) is not built/tested for high frequency of changes,

means that high-frequency changes are not intended for 1) the HTML via the virtual document text changes or 2) via the javascript running in the virtual document preview modifying the DOM.

Could we have some clarification here? Is a custom UI via HTML, javascript, and web-sockets a dead-end solution (that will break in the future)? Will an API be provided in the future or is it an intended limitation? Are the devs willing to support hosting a custom UI in the preview as a stop-gap solution until a proper API is provided?

I can accept that the vscode devs are too busy to implement or even specify such an API right now. But some guidance here would help because we extension developers are impatient and willing to rely on hacks.

[jrieken]

First: What you are doing is pretty cool - sending out some html and talking back via web sockets to your extension is a clever solution. I am glad that virtual documents make your life a little easier, btw even wrt to styles

The intended use-case for virtual documents and the previewHtml-command is something like 'showing source from a dll-file' or 'generating html from markdown'. The assumption is that those things aren't huge and that they don't update like crazy.

When it comes to UI we try to be smart - our tree and editor widgets are fully virtualised, render with the screen-refresh-rate, use diff'ing smartness etc. That's all for the sake of 'snappy VS Code'. The html preview part doesn't employ such techniques. And since (unlike extensions) it runs in the same process there is a chance of it wrecking VS Code and that's not what we want.

So when it comes to updating a virtual document at a high rate you should not use the onDidChange event because that's not cleverly implemented (yet?).

Keep doing the smart thing you already do - we won't break you in the foreseeable future but it also depends on how well extensions doing this behave. If things like this cause VS Code to stall we have to react (at least blame the extension ;-))

[siegebell]

@jrieken: Thanks!

Once Chrome is done implementing OOPIFs (issue 99379 and spec) there could be a way to run extension UIs in a separate process. Maybe in the same process as the extension, allowing it direct access to the DOM? Hmm...

[watzon]

This would be a super nice feature to have! I would love to be able to modify the document tree a little bit so as to filter out some files that are junking up my view but I have to keep.

[bgashler1]

Related #459

[nulled666]

I would like to have some UI APIs that could help me create popup panels for css value tuning.

[be5invis]

A dirty hack to do this: https://github.com/be5invis/vscode-custom-css
Waiting official API. :(