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 (#123)~ - marked as done in https://github.com/microsoft/vscode/issues/211#issuecomment-244362718
• ~adding support for custom tabs, the possibilities of the quick box is very limited (#710)~ - marked as done in https://github.com/microsoft/vscode/issues/710#issuecomment-385573949
• 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]

:+1:

[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]

:+1:

[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.).

[kabirbaidhya]

vscode is a great code editor with a lot of features and the hackability it provides the only thing it doesn't have is a good UI and look & feel. I think it's really important to provide the ability to customize the UI as much as possible so that the community can come up with some better themes.

[Fred-Vatin]

I think it is a duplicate of this Support to theme the entire workbench #3112 issue.

[NoNameProvided]

I would say #3112 is the duplicate of this as 1833 < 3112

[orta]

Looks like out of process iframes (OOPIFs) are being shipped in Chrome and so it may be available to be exposed in electron

[rei-vilo]

Any plans to improve the GUI features of Visual Studio Code? Last release 1.17 of Atom features docks.

[tilda]

Any updates on developments for this? Last update by devs for this was 4 months ago and we haven't seen anything happen since.

edit: #3112 shows that themes for workbench is out, but any other things to be covered besides this?

[marcoms]

It looks to me like VSCode isn't planning to be as flexible as Atom in this regard, instead prioritizing surface level adjustments like colors, fonts, etc. This will probably be better for performance, but personally I prefer Atom's tradeoff.

We close this issue and reference other related issues that were mentioned in discussions in this issue as follow up:

Theming for Font, spacing, images, borders, etc. (#23475) Font as setting (#519) Custom titlebar on windows (#16363) Separate syntax and workbench theme (#25986)

[RobertBColton]

+1 #5604 is related too. So many more extensions would be possible if UI customization was more robust. I need the ability to create custom editors with checkboxes, dropdowns, and form fields to edit metadata files for a game engine. Since an image editor that can preview images instead of showing them as blobs in the text editor was already added, it should be possible to create more of these kinds of editors as plugins.

I love VS Code for its performance and would like to use it as a replacement for other tools. But Atom clearly has the advantage as far as extension authoring goes.

[cwtuan]

Any update?

[HarisHashim]

Is @marcoms comment on Jun 21 means that this issue is dead. Ie. the VS Code team will not provide such extension capability of Atoms as commented by @rei-vilo .

If so, will be sad indeed!

[orta]

If you go through the chrome issues, out of process iframes have been in development for a while and seem to be wrapping up. So figuring out how that could work with electron and then vscode would probably be useful for this feature.

On Oct 4, 2017 22:34, "HarisHashim" notifications@github.com wrote:

Is @marcoms https://github.com/marcoms comment on Jun 21 means that this issue is dead. Ie. the VS Code team will not provide such extension capability of Atoms as commented by @rei-vilo https://github.com/rei-vilo .

If so, will be sad indeed!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/1833#issuecomment-334342348, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC_jrYIkxRwgD_cHd3tj6ovaknLPOKdks5spEAtgaJpZM4G_wxy .

[marcoms]

@rei-vilo, those plugins are designed for Atom, and do not work universally across Electron apps

[watzon]

@rei-vilo expanding on @marcoms comment, I think you are confusing Electron with Atom. Electron is a javascript framework that allows you to make chromium based desktop applications using javascript and HTML. Atom is an open source text editor built by the folks at GitHub that was built using the Electron framework.

[rei-vilo]

Ok, thanks!

[mrpotatoes]

This is really unfortunate as when I started to use VS Code this week I was actually really excited about it's system but if I can't customize it's GUI much if at all then I don't see the point in using this over Atom.

[watzon]

@mrpotatoes VS Code is newer than Atom still so give it some time to catch up. It's also faster by a lot and haing plugins written in Typescript by default it awesome

[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 https://github.com/Microsoft/vscode/issues/1833 and documentation integration (e.g. with Doxygen) https://github.com/Microsoft/vscode/issues/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 defaultfloating,dockedto 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: https://github.com/microsoft/vscode/issues/1833#issuecomment-455878771 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.