Vscode: Support to theme the entire workbench

[SetTrend]

Currently, color themes are not getting applied to the toolbar on the left:

I tend to believe this is not intentional as it inhibits accessibility, e.g. with high-contrast themes.

So I propose to have themes apply to the VS Code toolbar, too.

[akamud]

+1. I get a lot of people asking for this for my theme. I assume a lot of theme developers do.

[MLefebvreICO]

Can we get some feedback on this ?

[Kainax]

+1 Please add sidebar coloring theme

[clssw1004]

Very much agree with

[lucsky]

+100

[nfantone]

Currently, themes other than the default tend to look kinda awkward when displayed alongside the toolbar and sidebar. See, for instance, how it can change the general look and feel when using something like VScode Custom CSS extension.

[be5invis]

+1

[leaxoy]

+1

[Tyriar]

Themes looks particularly bad when the background is neither particularly dark or light:

https://marketplace.visualstudio.com/items?itemName=rebornix.nova

[flowchartsman]

The status bar at least is particularly hideous with monochrome schemes, like this port of MonochromeSublimeText Amber I'm working on. The abrupt change in hue and brightness makes it hard to use for any length of time.

Can't wait until you guys get this done!

[bgashler1]

Part of doing this is tracked in work item #8151. We're in the process of evaluating how to do this.

@alaska we are also definitely aware of requests for theming the status bar. We will be addressing at some point as well #1884.

[obskyr]

I'm very glad this might get implemented. I've got some themes that look absolutely lovely with their intended surrounding colors, but horrendous in the blue-gray surroundings VS Code gives you.

[bgashler1]

@caiusCitiriga We are working on this right now (but we don't have a date yet as to when it will be in the product).
https://github.com/Microsoft/vscode/issues/15927#issuecomment-262598086

[bgashler1]

Proposal

Summary

• Add “UI Theme” contribution to API
  
  
  
  • Make UI themes simple to create, like TextMate themes—or our JSON settings, which can be created by merely understanding XML or JSON.
  
  
  • Allow extensions to contribute one or more of following at once (as a theme pack)—UI theme, editor theme, and/or icon themes.
  
  
  • Provide color keys for all major parts of the UI.
  
  
• Create UI themes to pair with all themes shipping with VS Code.
• Add additional TextMate keys
  
  
  
  • Peek view background color and current line highlight for peek view
  
  

The UI components that can be themed

Proposed syntax

{
    "themeType":"dark",
    "activityBarBackground": "#333333",
    "badgeNotificationsBackground": "#007dc7",
    "shellTextForegroundColor": "#ccc",
    "viewletBackground": "#252526",
    "focusOutlineColor": "#9c0e0e",
    "messageBoxBackground": "this.viewletBackground",
    "statusBarBackground":"this.activityBarBackground",
    "panelBackground":"this.viewletBackground",
    "peekViewBackground":"#011f32",
    "inputArea":"#3c3c3c",
    "inputAreaSelection":"darkDefault.inputAreaSelection"
}

[be5invis]

Only colors?

[bgashler1]

If we initially support only colors, will this meet your needs?

[be5invis]

Font, spacing, background images, etc. Follow what Sublime supports.

[caiusCitiriga]

The ability to work on colors sounds great!

[leaxoy]

looks great!! but can we change it like sublime on icon shape, design(change all style to material or seti or others), look face(remove some button or viewlet, add some button or viewlet)

[akamud]

Some people ask me to provide a Dark and a Light theme, would this "UI Theme" contribution allow for having a light and a dark theme from the same extension?

[rozzzly]

I say just allow users to put their own stylesheet in their project's .vscode directory, globally in ~/.vscode, or via an extension contribution. _(Ordered: greatest --> least priority)_ Similar to how atom does it. This way, there doesn't need to be a whole new convoluted system! Seriously! Why go through all the trouble of making some tmTheme-esque configuration format with a custom parser when it's just going to append a <style></style> tag to the DOM any way?? The beauty of tmTheme for colorizing the editor is that it opened up a huge library of preexisting themes without needing to do any manual conversions. But that's not possible with styling the workbench because that is specific only to vscode.

Let the user supply css, append that stylesheet behind workbench.main.css in the DOM, and the cascading nature of css should take care of the rest. And if there's a part of the workbench that I want to theme, all I need to open up Dev Tools, find the relevant css class and add it to my theme file.

If the UI team goes for a custom config format for then:

• A bunch of time is going to be wasted to implement the more complex configuration system.
• Users/extension authors will be limited to whatever fields the UI team decides to explicitly allow.

Sure, being able to change the colors would be cool, but what if I wanted to move the activity bar to the top of the screen? Make the quick pick widget fade in? What about adjusting some padding? Or even just change a color value that the parser doesn't recognize yet? In each of those cases I would have to post an issue on GitHub and then hopefully after a week or two that setting would land in the nightly insiders build.

So I don't see why a custom format is necessary. Just allow css.

[obskyr]

I do kind of agree with @rozzzly - but since the current theme support isn't CSS, it wouldn't make much sense. It'd be pretty great if the entire theme framework was just CSS (with TextMate-like themes for backward compatibility), but that'd be quite the change.

In the absence of CSS theme support, the JSON-style ones are okay enough. Though they should definitely be integrated into the normal theme files - there shouldn't be a difference between styling the text area and styling the sidebar (and the like). Having a separation between a theme and a "UI theme" makes no sense and wouold just make for annoying upkeep on the user's part. Though maybe that's not what @bgashler1 meant.

[Tyriar]

@rozzzly the main argument against that is that then the DOM itself becomes an API, but one that will change between versions. The structure of VS Code's DOM is ever changing, having extensions (or individual CSS files) depend on this would break extensions that depended on it. If we define a strict API for doing these things, that is us committing to it so it won't break every version, and you as an extension author will not get pissed off with having to fix your theme every 1-3 months.

[obskyr]

@Tyriar Ah, that's true, isn't it. Regardless of that, though, it'd be really off if it was a separate system - adding new keys would suffice.

[Tyriar]

@obskyr we've discussed the difference between UI and syntax themes quite a bit and despite my original thoughts which were similar to yours, they should remain separate for a few reasons:

• .tmTheme files are what do the theming of the editor, this is an existing format and has a number of issues:
  
  
  
  • It's xml (ugly and verbose).
  
  
  • They should remain portable across editors, meaning adding fields to them in a compatible way is restricted to a flat list of global properties at the top of the theme.
  
  
• But most importantly: people want to be able to theme the workbench different to the editor so there is greater contrast between them.

Much like with the icon themes that we introduced before, if we rolled them into the current themes there would be heaps of variants of the same theme with different icons, of varying degrees of quality, making the ecosystem more fragmented and lower quality overall.

[obskyr]

@Tyriar You really do have to be able to bundle them with a theme, though. A separate UK theme "override" could solve the problem you're talking about... if it's even a problem. Icons are not in the same category as the colors of what after all is just another part of the window. After all, you could just as well make the argument that users should have a separate theme for just text color, so they can make sure there's a greater contrast between it and the background.

Having users manually install two things each time they want a visually congruent theme is not a good idea. Neither graphic design-wise nor usability-wise.

[rozzzly]

@Tyriar you're right, but I think the level of control potentially gained is paramount to a little bit of uncertainty for parts of the UI that are in flux. Yes it is possible that my workbench theme might break after a few versions, but the alternative suggestion isn't perfect either. Lets pretend this hits in 1.9: I run 2.0 and make an extension that depends on activityBarIconBackgroundHover which was introduced in 2.0, but you run 1.9 still. Now my extension won't work for you, whereas it probably still would with the way I propose.

@obskyr I think that separating Editor Themes and Workbench Skins would be the smart way to go. @Tyriar makes a really good case for why they should be seperate.

Moreover, when you say:

Having users manually install two things each time they want a visually congruent theme is not a good idea. Neither graphic design-wise nor usability-wise.

Lets say I want to make my activity bar blue, yet maintain the ability to use the 100s of the existing editor themes. Following your suggested approach, I'd have to create a new extension which contains that that editor theme and my workbench edits. It'd fill up the marketplace with tons of copies of the theme but with tiny tweaks.

What about having an extension that contributes both? That would work really well. Then I just need to select the theme and the workbench skin. No need to look for matching files, just select the menu options My Really Cool Theme and My Really Cool Skin. Then I could say, "ooooh I like that workbench skin, but the syntax highlighting isn't what I want... So I'll just use the workbench skin and a editor theme that I do like!"

[obskyr]

@rozzzly I really don't want to have to look for another file whenever I install a theme. Especially if the author doesn't make a UI theme to go with it - that sends you on a fool's errand of locating a UI theme that kind of fits with your editor area, but not really.

[Tyriar]

@rozzzly extensions can actually protect against that now as you specify a minimum version that the extension can work on, it's the other way that's more dangerous; depend on #some-component in 1.9 which goes away in 2.0 and you don't update the extension, this extension now stay broken in the marketplace until the end of time!!! :scream:

@rozzzly @obskyr the flow for actually getting applying the 2 theme types in a nice way is a concern and I agree needs some more thought. This is not particularly user friendly:

1. Download editor theme foo
2. Download UI theme bar
3. Set foo as active
4. Set bar as active

[obskyr]

@Tyriar If separate sidebar and editor themes is really something people would want (which I'm, again, not sure of – I'm fairly certain Atom doesn't do it, for example), there is another option. Consider the following flow:

1. Download combined theme x.
2. Apply combined theme x, with a command as usual.

So far, so good. No change in flow if you just want to install one theme. But here's where it gets interesting:

1. Download combined theme y.
2. Apply the UI part of theme y, using another command.

With this approach, themes are combined UI and editor themes, making for a unified design and making it more natural as a theme designer to create them together. As a user, you then have three commands:

• Apply theme (editor + UI)
• Apply UI (part of) theme
• Apply editor (part of) theme

This even lets the themes be in the same file - just categorize the JSON keys into "UI keys" and "editor keys" internally. The Apply UI theme command only applies UI keys, the Apply editor theme command only applies editor keys, and the Apply theme command applies both.

[Tyriar]

@obskyr Atom has a UI theme and a syntax theme very similar to what we're considering:

As for your proposed flow, I was thinking something along the same lines but it's still kind of messy to type theme into the command palette and get:

• Apply icon theme
• Apply theme (editor + UI)
• Apply UI theme
• Apply editor theme

Pretty confusing if you're a new user imo. Anyway, it will surely be a topic for discussion in some upcoming UX meetings.

[obskyr]

@Tyriar How about this, then.

• Apply color theme
• Apply icon theme
• Apply color theme to only to UI
• Apply color theme only to editor

Beyond the fact that you might want to consider the terms "UI" and "editor", perhaps these expanded wordings better the situation.

[be5invis]

@Tyriar @bgashler1
Please give some ability to set font faces to UI elements. I prefer Neo-Grotesque instead of Humanist, so:

{
    "shellTextFontFamily": "Aktiv Grotesk"
}

or, being more powerful:

{
    "shellText": {
        "color": "#ccc",
        "fontFamily": "Aktiv Grotesk",
        "zh-CN": {"fontFamily": "Aktiv Grotesk CN PRC"},
        "zh-TW": {"fontFamily": "Aktiv Grotesk TWHK"}
    }
}

[druellan]

Mind that Atom also has polymorphic themes that adapt to the color of the syntax theme, so, having individual UI and syntax themes allows you to do some nice tricks like that one.

[schmuli]

I agree that keeping UI themes separate from Syntax themes is the correct way forward.

For concerns of having to install two extensions, can't that be mitigated by using an Extension Pack?

Regarding the UI controls for selecting which Theme to apply:

The whole UI for selecting themes should change, to be a single UI for selecting all themes. But I don't think having menu items/commands for each + combined will be a very good UX.

In fact, why don't the selected themes (color, icon) even appear in the User/Workspace settings? Then the user could just select at the same time which UI, Syntax and Icon theme they want, without having to select multiple menu items/commands.

[kutsan]

What is the current status?

[be5invis]

Yeah, any progress?

[bgashler1]

We are doing at least _some_ of the work, I believe, in the January iteration #17608

[equinusocio]

@bgashler1 Any update about this issue? 1.9.0 release missed this feature :(

I think a custom .css file provided by users or extensions would be awesome. The only question is about priority if multiple files are loaded. As a Material Theme developer i think that we need more controls over UI, and a lot of settings like

{
    "themeType":"dark",
    "activityBarBackground": "#333333",
    "badgeNotificationsBackground": "#007dc7",
    "shellTextForegroundColor": "#ccc",
    "viewletBackground": "#252526",
    "focusOutlineColor": "#9c0e0e",
    "messageBoxBackground": "this.viewletBackground",
    "statusBarBackground":"this.activityBarBackground",
    "panelBackground":"this.viewletBackground",
    "peekViewBackground":"#011f32",
    "inputArea":"#3c3c3c",
    "inputAreaSelection":"darkDefault.inputAreaSelection"
}

is not the best thing..

[Tyriar]

@equinusocio the issue with direct access to CSS is that the styles will inevitably break over time, as the editor is transformed. Either that or we lose mobility by making (parts of?) the DOM API.

The proposal here https://github.com/Microsoft/vscode/issues/3112#issuecomment-263438933 would not be in settings.json but encapsulated within a "UI theme" extension, so they are written once and used by many consumers. This distinction between UI and syntax themes is to provide greater contrast between the editor and the workbench as I've heard this from several people.

[equinusocio]

@tyriar ok thanks, but i think even if this internal settings change we have to update the extension. So there is no difference between change css or settings. Or not?

[Tyriar]

@equinusocio we would define settings as part of the API and then they will not change. Nothing is stopping the VS Code team right now from changing whatever in the DOM they want whether it be for refactoring, performance or whatever reason.

If it was a list as proposed then you should expect it to work until :sparkles: the end of time :sparkles: .

[equinusocio]

@Tyriar Thank you.

@bgashler1 I can suggest more UI settings like paddings/margins, foreground colors and status specific settings like buttonsHoverBackground and buttonsActiveBackground and so on..

Also replacing UI icons would be awesome. Like "sidebarNewFolderIcon": "./new-folder-icon.svg", maybe in the next releases.

[martinsuchan]

If this is already planned for the February release, any plans to make the Menu bar #16363 and Status bar #1884 theme-able as well?

[bpasero]

Due to vacation this will slip into March milestone. It is still a # 1 priority for us to deliver this asap.

[nomad-software]

@bgashler1 Please don't forget to include functionality to theme the reference pop-up window. Thanks.

[bradenhs]

It's a small detail, but I could definitely see theme developers wanting to control the _shadow color_ of scrollable areas. For example, if the background color of the explorer and the editor are the same you can have shadows that end abruptly as shown here. Don't know if it's in the plan to expose this in the API or not but it'd be nice if it was.

[jens1o]

So, after all, how will it be implemented? I do prefer the (s)css way, because I just want to change something on my own, and I don't want to write some additional package.json etc.. That way, it would be so complicated to change just a simply thing; what the editor does look like(small tweaks...).

[bpasero]

Our strategy at the moment is to look into colors that are used throughout the system and "externalize" them so that the values can be changed dynamically (I use the word "externalize" here because for strings we do something similar to support translation into different languages).

For example, we have a background color for the panel (where output, integrated terminal etc.) is. This color happens to be the editor background color by default, but a theme author or user might want to change it. So we are introducing a color for this area (let's call it panelBackground) that a theme author can change.

Once we did all this, we can also think about allowing users to change these colors via settings. There could be a global settings entry for all colors in the system and overriding a color applies it over the color defined by the theme.

We start with colors, but it may not be limited to colors. Fonts are also interesting, but changing the font type and size has a bigger impact on the overall UI that needs more thinking. In many places we have pixel perfect layouting code that makes assumptions based on the default font we define and those assumptions would no longer work when these are configurable by the user.

[jens1o]

so no (s)css customization? 😢 @bpasero

[bpasero]

so no (s)css customization?

I am not saying we never support it but the scope of this plan item is to add more colors to the themes we are already shipping and enabling all extension themes to add their colors to more parts of the workbench. As such, we need to support the current theming format and add more colors to it. A solution that would require SCSS seems impractical given the format for themes is already established (simple key values).

[be5invis]

@bpasero You can have more options, maybe like Sublime, giving the ability to customize background/typography/borders/icon, etc.

[varemenos]

@be5invis that's probably something they are planning to add in a future version (assuming this one goes well).

[octref]

so no (s)css customization?

I hope no css customization even in the future, as it introduces too many ways people can possibly break VSCode's layout.

[stezu]

I think it would be a fair compromise to add some kind of "experimental" option that allows you to load a custom stylesheet. There will be no expectation for that stylesheet to work between versions, but it will allow people to style everything they want to.

As more areas are available to style via a key/value pair system, that experimental feature will be less necessary for the average user and we get the best of both worlds. Is such an approach under consideration?

[octref]

I think it would be a fair compromise to add some kind of "experimental" option that allows you to load a custom stylesheet.

https://marketplace.visualstudio.com/items?itemName=be5invis.vscode-custom-css
Beware it modifies VSCode source code and could lead to unexpected behaviors.

There will be no expectation for that stylesheet to work between versions

People will expect so if VSCode adds support for it. Just pasting what @Tyriar said:

@rozzzly the main argument against that is that then the DOM itself becomes an API, but one that will change between versions. The structure of VS Code's DOM is ever changing, having extensions (or individual CSS files) depend on this would break extensions that depended on it. If we define a strict API for doing these things, that is us committing to it so it won't break every version, and you as an extension author will not get pissed off with having to fix your theme every 1-3 months.

One the one hand, I also enjoy customizability, but I hope my customization can be continuously supported in VSCode, not some CSS hack that I have to update with each version of VSCode.

On the other hand, having the DOM structure decoupled from config and extension API allows VSCode to iterate fast to add features & optimizations.

[imoby]

This got moved to April?

[bpasero]

We got something working, but we are not done for March.

[schmuli]

@bpasero Amazing progress so far, very cool to see so many commits every day. 🥇

[octref]

@bpasero
Seems some code is already in master for this feature.
Is the setting format finalized? If so it would be nice to have it in Insider between March and April. Also this gives theme authors time to adapt.

[equinusocio]

:(

[akamud]

Definitely should be released to Insiders with docs so we can adapt before a final release.

[jens1o]

:( would loved to see this this month. I was looking for the next release... :/

[bpasero]

Our plan is to document this for March to enable early adopters, stay calm and be happy ⭐️

[martinsuchan]

@bpasero Any update about the Menu bar theming support?

[bpasero]

@martinsuchan our theming support is currently limited to what can be done via DOM APIs, but does not cover native elements outside that area (like the menu bar).

[equinusocio]

@bpasero And what about the app title bar?

[be5invis]

@bpasero What does it currently support? Only colors?

[bpasero]

Yes only colors. If you are using the custom title bar on macOS, that one is covered as well because it is done via HTML.

[wprater]

@martinsuchan our theming support is currently limited to what can be done via DOM APIs, but does not cover native elements outside that area (like the menu bar).

@bpasero can we expect support for setting -webkit-font-smooting on each part? e.g. setting a value on the status bar and explorer and another on the editor pane?

[pseudo-su]

I've switched to insiders so I can test the Solarized Dark theme.

I'm not sure if these are issues with the theme or the theming support but I've tried to find all the ui areas that I think aren't themed yet. Some are pretty minor but hopefully it helps.

Autocomplete box

Background on startup

Button outline in debug panel

Disable and uninstall buttons

Vscode feedback popup

Right sidebar in git diff view

Search and replace dropdown on hover

Selected tab underline in bottom tray

Total settings count background and gray lines

Sidebar file selection highlighting.

Selected (blue), hovered (dark gray) and out of focus (lighter gray)

Welcome page quick links

[equinusocio]

@bpasero So at the moment we can only change the statusbar color?

"workbench.experimental.colorCustomizations": {
    "statusBarBackground": "#00EECC",
    "statusBarNoFolderBackground": "#CCEE00",
    "statusBarDebuggingBackground": "#CCFFFF"
}

[bpasero]

@psuedoSudo thanks, maybe you could add this to https://github.com/Microsoft/vscode/issues/23506 where we already collect missing elements. We are well aware of some, since we have not adopted all widgets yet (e.g. like the tree/list widget that is pretty much everywhere).

@equinusocio no, the list of colors is larger. Once you open intellisense in settings you will see all:

[equinusocio]

@bpasero Ah nice work! There will be a documentation section about that API?

[bpasero]

Yes, we are just wrapping up for the March release and plan to document theming soon. We still expect many changes to the theming API though (color keys) during April.

[equinusocio]

Oks! Thank you!

[Shulin]

I'm very excited about this. Are we going to be able to change the text color/format of tabs via extensions?

[equinusocio]

@bpasero How we can define settings inside the extension? there is a place to put the colors settings? I have a textmate theme, not a json schema

[pmkary]

Thanks a lot for the new update, We all wanted for this so much ❤️

One thing: As I mentioned in #21938 it would be really really cool if the activity bar could be themed light. And the problem still exists because the icons remain white:

[flying-sheep]

for themeable icons, i suggest to adapt KDE’s approach

(and please no slight modification of it, it would be amazing if something in the software would would be actually compatible for once)

[aeschli]

@flying-sheep Thanks for the link, didn't know that trick!

[flying-sheep]

idk if it’s a trick, but the idea is of course to replace the <style id="current-color-scheme"> with the right color definitions, see here

[pmkary]

@flying-sheep what a nice system!

[dakaraphi]

Are the plans to be able to customize the search results view?
I would very much like to customize coloring of file names, folders, result highlighting etc.

[patrik-martinko]

It would be nice to change:

• the color and transparency of scrollbars
• the color of titlebar on Windows

[bpasero]

Support for theming the workbench has landed for April release (1.12.x) and is documented in our release notes: https://code.visualstudio.com/updates/v1_12#_workbench-theming

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)

We still plan to add more components that are themable as we see fit and requests for.