search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.32k stars 29.31k forks source link

Support to theme the entire workbench #3112

Closed SetTrend closed 7 years ago

SetTrend commented 8 years ago

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

code theme

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 commented 8 years ago

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

MLefebvreICO commented 8 years ago

Can we get some feedback on this ?

Kainax commented 8 years ago

+1 Please add sidebar coloring theme

clssw1004 commented 8 years ago

Very much agree with

lucsky commented 8 years ago

+100

nfantone commented 8 years ago

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.

screen shot 2016-09-16 at 11 55 23 am
be5invis commented 8 years ago

+1

leaxoy commented 8 years ago

+1

Tyriar commented 8 years ago

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

image

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

flowchartsman commented 8 years ago

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. barf

Can't wait until you guys get this done!

bgashler1 commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

Proposal

Summary

The UI components that can be themed

screen shot 2016-11-28 at 4 18 14 pm

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 commented 7 years ago

Only colors?

bgashler1 commented 7 years ago

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

be5invis commented 7 years ago

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

caiusCitiriga commented 7 years ago

The ability to work on colors sounds great!

leaxoy commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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:

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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:

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 commented 7 years ago

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

image

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:

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

obskyr commented 7 years ago

@Tyriar How about this, then.

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

be5invis commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

What is the current status?

be5invis commented 7 years ago

Yeah, any progress?

bgashler1 commented 7 years ago

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

equinusocio commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

nomad-software commented 7 years ago

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

bradenhs commented 7 years ago

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.

screen shot 2017-02-28 at 8 59 15 pm

jens1o commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

so no (s)css customization? 😢 @bpasero