Closed NatoBoram closed 7 months ago
My main objection to this is that the white and brightWhite colors are identical. UI elements that are meant to be distinguishable may look exactly the same with this scheme, or in some cases text could be completely invisible.
white
could take the colour of cursorColor
, #cccccc
, for better legibility on Windows Terminal. That wouldn't deviate too much from Dark+.
Yeah, I was thinking the same thing. We may not want to deviate from the original colors if there is an official source somewhere, but I see that the iTerm2 Themes collection has a Dark+ color scheme which is very different from this, so maybe it's less of an issue in this case.
If the name Dark+
is prone to conflict, I think it would be appropriate to rename it to Visual Studio Code
. I haven't seen it outside of VSCode and the name is too generic, which lead me to think it's a completely original colour palette made specifically for VSCode.
These are my proposed schemes:
"schemes": [
{
"name": "VSCode Light",
"foreground": "#333333",
"background": "#fffffe",
"black": "#000000",
"red": "#cd3131",
"green": "#00BC00",
"yellow": "#949800",
"blue": "#0451a5",
"purple": "#bc05bc",
"cyan": "#0598bc",
"white": "#555555",
"brightBlack": "#666666",
"brightRed": "#cd3131",
"brightGreen": "#14CE14",
"brightYellow": "#b5ba00",
"brightBlue": "#0451a5",
"brightPurple": "#bc05bc",
"brightCyan": "#0598bc",
"brightWhite": "#a5a5a5"
},
{
"name": "VSCode Dark",
"foreground": "#CCCCCC",
"background": "#1E1E1E",
"black": "#000000",
"red": "#cd3131",
"green": "#0DBC79",
"yellow": "#e5e510",
"blue": "#2472c8",
"purple": "#bc3fbc",
"cyan": "#11a8cd",
// "white": "#CCCCCC", // Matches foreground
// "white": "#e5e5e5", // As defined in VS Code
// "white": "#a5a5a5", // Darker to have different foreground and white
"white": "#D8D8D8", // Average of VS Code definition and the foreground
"brightBlack": "#666666",
"brightRed": "#f14c4c",
"brightGreen": "#23d18b",
"brightYellow": "#f5f543",
"brightBlue": "#3b8eea",
"brightPurple": "#d670d6",
"brightCyan": "#29b8db",
"brightWhite": "#e5e5e5"
},
{
"name": "VSCode HC",
"foreground": "#FFFFFF",
"background": "#000000",
"black": "#000000",
"red": "#cd0000",
"green": "#00cd00",
"yellow": "#cdcd00",
"blue": "#0000ee",
"purple": "#cd00cd",
"cyan": "#00cdcd",
"white": "#e5e5e5",
"brightBlack": "#7f7f7f",
"brightRed": "#ff0000",
"brightGreen": "#00ff00",
"brightYellow": "#ffff00",
"brightBlue": "#5c5cff",
"brightPurple": "#ff00ff",
"brightCyan": "#00ffff",
"brightWhite": "#ffffff"
}
]
I pulled these definitions from the VS Code source. As was pointed out, there are some issues with White. I hadn't submitted a PR to implement these because there is a conflict with how best to implement White with respect to VSCode Dark. I've been using the White as defined here with high success and this is actually the color scheme I have for most of my terminals right now. I think as a further extension, schemes should also have an ability to choose for intensity the ability to use bold, or select a brighter color as is the terminal default right now. This could be introduced as a property for a scheme like "intensity": "bold"
or "intensity": "bright"
. This would make this a good scheme to introduce and promote this capability as intensity in VS Code is actually shown as bold rather than increased brightness as the console has traditionally utilized.
I also pulled in from the source the definition of High Contrast, although it is very close to Vintage with some very subtle adjustments.
As a further point of discussion, this is how the VSCode Dark looks:
and this is VSCode Light:
For completeness, this is VSCode HC:
I reviewed the definitions and this is as they are defined. Some colors like red, blue, magenta (purple), and cyan are the same for the regular color and the bright color definitions for the Light scheme. I think those should be fixed, but it does match the source.
Okay, I think I'm okay with the idea of this - it's well sourced, the "VSCode *" names won't conflict with something else. Though, Dark+ on iTerm2-Color-Schemes does look like it's the same thing to me. It makes sense to me to include this theme with the Terminal, esp. considering there's product synergy (or some corporate spiel like that)
I think we'll need to come up with an official party line though regarding what schemes we can include by default and which we shouldn't. We've already gotten ourselves into a mess with the Solarized themes. We probably don't want to unnecessarily clutter the defaults file (otherwise we'd just import everything from https://github.com/mbadolato/iTerm2-Color-Schemes immediately). This is something relevant to discussions we're having with @cinnamon-msft.
For now, I'm okay with a PR to add these.
So, I took the time to take screenshots of Dark+, Light+ and High Contrast to reveal the apparent colours. VSCode might apply some transformations to the terminal's colours, giving a different result than from the source code, which might explain why @rbeesley's red #cd3131
doesn't match #c62f37
. I personally want to see the actual VSCode terminal theme and not an interpretation of the source code. We might need to contact someone who's actually on the VSCode team, though, to know what's really happening here.
cc @bpasero, @iansan5653, @Tyriar, @sbatten
Here's the colours I picked (excluding foreground
).
[
{
"name": "Dark+",
"foreground": "#cccccc",
"background": "#1e1e1e",
"cursorColor": "#cccccc",
"black": "#000000",
"red": "#c62f37",
"green": "#37be78",
"yellow": "#e2e822",
"blue": "#396ec7",
"purple": "#b835bc",
"cyan": "#3ba7cc",
"white": "#cccccc",
"brightBlack": "#666666",
"brightRed": "#e94a51",
"brightGreen": "#45d38a",
"brightYellow": "#f2f84a",
"brightBlue": "#4e8ae9",
"brightPurple": "#d26ad6",
"brightCyan": "#49b7da",
"brightWhite": "#e5e5e5"
},
{
"name": "Light+",
"foreground": "#333333",
"background": "#ffffff",
"cursorColor": "#333333",
"black": "#000000",
"red": "#c62f37",
"green": "#30bf03",
"yellow": "#929a0d",
"blue": "#214da4",
"purple": "#b700bc",
"cyan": "#3297bb",
"white": "#555555",
"brightBlack": "#666666",
"brightRed": "#c62f37",
"brightGreen": "#3ad116",
"brightYellow": "#b3bc13",
"brightBlue": "#214da4",
"brightPurple": "#b700bc",
"brightCyan": "#3297bb",
"brightWhite": "#a5a5a5"
},
{
"name": "High Contrast",
"foreground": "#ffffff",
"background": "#000000",
"cursorColor": "#ffffff",
"black": "#000000",
"red": "#c50015",
"green": "#35d003",
"yellow": "#cbd017",
"blue": "#2800ed",
"purple": "#c800cd",
"cyan": "#40cdcc",
"white": "#e5e5e5",
"brightBlack": "#7f7f7f",
"brightRed": "#f5001d",
"brightGreen": "#44ff05",
"brightYellow": "#fcff1f",
"brightBlue": "#6551fe",
"brightPurple": "#f800ff",
"brightCyan": "#52fffe",
"brightWhite": "#ffffff"
}
]
After testing Light+ and High Contrast, I have to say... Those themes are unfortunate looking.
Here's the colours I picked (excluding foreground).
If you want the actual colors the terminal uses in VS Code you can run the Developer: Generate Color Theme From Current Settings
command.
I personally want to see the actual VSCode terminal and not an interpretation of the source code.
This will likely happen in the form of pulling the terminal/panel out into a separate window which is tracked in https://github.com/microsoft/vscode/issues/34442 and https://github.com/microsoft/vscode/issues/10121
I think as a further extension, schemes should also have an ability to choose for intensity the ability to use bold, or select a brighter color as is the terminal default right now.
This is driven by the terminal.integrated.drawBoldTextInBrightColors
setting in VS Code. There are also related terminal.integrated.fontWeight
and terminal.integrated.fontWeightBold
settings to give you control of bold.
Now that's some better sourcing.
{
"terminal.ansiBlack": "#000000",
"terminal.ansiBlue": "#2472c8",
"terminal.ansiBrightBlack": "#666666",
"terminal.ansiBrightBlue": "#3b8eea",
"terminal.ansiBrightCyan": "#29b8db",
"terminal.ansiBrightGreen": "#23d18b",
"terminal.ansiBrightMagenta": "#d670d6",
"terminal.ansiBrightRed": "#f14c4c",
"terminal.ansiBrightWhite": "#e5e5e5",
"terminal.ansiBrightYellow": "#f5f543",
"terminal.ansiCyan": "#11a8cd",
"terminal.ansiGreen": "#0dbc79",
"terminal.ansiMagenta": "#bc3fbc",
"terminal.ansiRed": "#cd3131",
"terminal.ansiWhite": "#e5e5e5",
"terminal.ansiYellow": "#e5e510",
"terminal.border": "#80808059",
"terminal.foreground": "#cccccc",
"terminal.selectionBackground": "#ffffff40"
}
That gives the following scheme :
{
"name": "Dark+",
"foreground": "#cccccc",
"background": "#1e1e1e",
"cursorColor": "#808080",
"selectionBackground": "#ffffff",
"black": "#000000",
"red": "#cd3131",
"green": "#0dbc79",
"yellow": "#e5e510",
"blue": "#2472c8",
"purple": "#bc3fbc",
"cyan": "#11a8cd",
"white": "#e5e5e5",
"brightBlack": "#666666",
"brightRed": "#f14c4c",
"brightGreen": "#23d18b",
"brightYellow": "#f5f543",
"brightBlue": "#3b8eea",
"brightPurple": "#d670d6",
"brightCyan": "#29b8db",
"brightWhite": "#e5e5e5"
}
"selectionBackground": "#ffffff",
@NatoBoram this would get blended with the background #1e1e1e
at 25% opacity (0x40
) to give `"selectionBackground": "#565656"
As a tool for being able to see these schemes applied in a terminal, I wrote this cmd script, ansi-colors.cmd, which can be used to put all the SGR parameters together. It is currently configured for showing 1, 4, 7, 30-37, 40-47, and 100-107, and the combinations of those which make sense.
While not written for creating this specific color scheme, I think this might be a tool worth adding to the repo to make it easier to see the different color combinations. It is all self-contained in one .cmd file with no necessary external dependencies. There is an option to use PowerShell to generate the ESC non-printable character, but in this gist it just uses one saved in the file. There is also an optional dependency on CHCP if the output is going to show Unicode, but it does not need to be required. It uses a data segment embedded in the file itself, so the definition of what is shown can quickly and easily be changed to something else.
Yea I'd welcome that PR. IMO the src/tools
directory is the perfect place for a helper like that βΊοΈ
@Tyriar It seems like Terminal already gives a different opacity to selectionBackground
. I tried to apply #565656
, but the result was way too dark. Without manually tweaking selectionBackground
, the result is a bit too bright. I think it's fine if we let Terminal use the original values of VSCode's theme in its own way, as long as it doesn't break any functionality.
Oh I assumed it would have been drawn as a background color. Just spotted https://github.com/microsoft/terminal/issues/3580 which will fix the a11y issue that comes from that π (well, in combination with selection foreground and/or https://github.com/microsoft/terminal/issues/3561)
opacity
Sorry about that. The original render engine from conhost that we started specializing never supported rendering backgrounds and text separately, so we had to improvise a bit. We've got work booked to fix that and make selection background AND FOREGROUND work properly.
Yea I'd welcome that PR. IMO the src/tools directory is the perfect place for a helper like that
Shouldn't it just be a modification for Color Tool?
Yea I'd welcome that PR. IMO the src/tools directory is the perfect place for a helper like that
Shouldn't it just be a modification for Color Tool?
I mean, ideally, yes. I'm open to the idea of "good" being better than "perfect" in this case, considering this is just a helper tool.
Just telling everyone, I would like to work on this. Thanks
@Chips1234, I encourage you to use my gist, ansi-color.cmd, to assist you with this endeavor. I've been distracted with work so I haven't been able to address the final layout situations I've been wanting to fix, but it is absolutely usable in its current form and I'm hoping to get some feedback.
Alright.
Any updates?
Not really. Adding this to the JSON is super trivial, but comes with a slight annoyance. Every scheme we include by default gets written back to the user's settings.json
file whenever the file gets saved, even if there are no changes to the scheme. That's kind of annoying. We kinda want to find a way around that before we ship any more in-box schemes.
Last I heard @DHowett had a prototype for remedying the settings, in #12800. Alas, we haven't had the cycles to close on that one yet. It's got a number of wacky edge cases.
Description of the new feature/enhancement
VSCode's theme, Dark+, is absolutely gorgeous.
I think it would be totally appropriate to add it to the default schemes.
Proposed technical implementation details (optional)