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. :(

[atian25]

+1

I have a similar feature request too: how to custom sort order of sidebar files?

[jakubnavratil]

👍

[redVi]

I like VS Code really. But I want see customizable and beautiful editor. Right now it looks like one of the tools of Windows. I have OS X and the interface of this editor should not dramatically different from the native interface.

[Revod]

Any update about this request?

[redVi]

@Revod apparently no more updates. About scroll bar: it would be cool to hide it. Like this

[be5invis]

@rebornix @joaomoreno any progress on this?

[Hendrixer]

like @be5invis said, https://github.com/be5invis/vscode-custom-css works pretty great. I was able to achieve this in just 20 mins

[chixu]

+1

[mszczepaniak]

@Hendrixer it looks great! Could You share Your config to achieve this colors?

[Revod]

@mszczepaniak @Hendrixer I want that config too please

[shaunlebron]

To be extra clear, VS Code does not support what Atom calls "UI Theme" below.
This can be jarring since syntax themes can clash with the surrounding UI.

Third party solutions hacks:

• vscode-custom-css
• vscode-custom-theme

[bgashler1]

@shaunlebron we are going to support this officially soon #17608 (no need for third-party solutions which hack the install and can make it unstable.).

[flyisland]

just took a look at the roadmap of 2018, it seems like the team still have no plan for this request on next year, too bad!

[rei-vilo]

@flyisland Thanks for the pointer. It looks like Microsoft has its own agenda, somehow disconnected from users' needs, as C / C++ may not have the hype or Node, JavaScript, or TypeScript. Better integration with `make` (by passing parameters on to, actually a show-stopper for me) microsoft/vscode-cpptools#742, better GUI options #1833 and documentation integration (e.g. with Doxygen) #25231 are low in priority, turning VSC into a walled-garden. VSC was high on my recommendations, but those missing features —especially the integration with make— and the lack of them in a foreseeable future made me revised my opinion and demote VSC.

[tracker1]

Was thinking that the way plugins run with VS Code, maybe exposing a render interface, similar to React's would be beneficial... this way the render method will return a virtual dom representation in the extension/plugin, and the interface then swaps out any attached methods for events with dispatchers that will dispatch through to the extension, and trigger that a fresh render is needed.

Even if a plugin's render takes too long, it won't hang the rest of the application...

it would be like react, but split across a boundary where the composition is in the plugin/extension, and the actual render-diff happens in vs code's UI.

[janaka]

Here's the use case I had in mind. Recently I've started contributing to the .NET Test Explorer extension. As far as I know it's the only extension available for working with unit tests in a .NET Core project. Having a powerful scalable (large number of tests) tool in this regard is important if VS Code is to be successful as the IDE for .NET Core development on MacOS. It's to have at least some of the testing power features as VS.

The explorer and command palette UI options are too limited for building such experiences. Currently .NET Test Explorer renders as an Explorer Tree view. It occurred to me earlier that a UI similar to the Search option in VS Code could be a good fit. Allowing a developer to quickly free text search for tests, filter in failing tests, and re-run just those tests with a keyboard shortcut would be an example workflow.

As far as I can tell there are no facilities at present to build such an experience as an extension.

[mrpotatoes]

It's on the docket!

Investigate promoting explorer contributions to viewlets #43645 @sandy081

(I know I said I couldn't use this over Atom but in the past month I've been using it over Atom so I'm interested in it's progress again. Forgive me)

[simon-robertson]

Personally, the "default dark" theme is fine for me. The only related request I have is to allow the status bar to have a "dark" theme as well, to match the rest of the GUI; the default blue theme is too distracting.

[rei-vilo]

Is the API behind the debugging toolbar available?

Tip: Use the setting debug.toolBarLocation to control the location of the debug toolbar. It can either be the default floating, docked to the debug viewlet or hidden. A floating debug toolbar can be dragged horizontally and also down to the editor area.

as per the Debugging page.

[rei-vilo]

It looks like @JerryGoyal found a solution with the Shortcut Menu Bar VSCode Extension.

In context, in the top-right corner:

[tristan957]

I am going to throw my hat in the ring as well. When Firefox supported GUI customization through XUL, I could permanently hide the horizontal tabs at the top. I would love to do this in VSCode. I think vertical tabs work better in some cases especially on wide screens.

I have made a feature request in #75749

[madushajg]

bump

[zvidan]

Hi @rei-vilo
You have mentioned the Debug toolbar above:
#1833 (comment)
Do you know, if some ability to change it (add button) does exist ?
In my opinion, "Show Next Statement" (as in classic Visual Studio) is mandatory here !

[rei-vilo]

@zvidan It has been a very long time since my comment. I suggest to open a new issue.