ColorTool: Background color not working correctly

[wavebeem]

ColorTool is not setting the background color correctly when I use it. I've tried the built-in themes and also my own .itermcolors files and they all end up varying shades of purple and pink.

Windows 10
Version 1703
Build 16251.1002

[Nacimota]

So up until very recently the console only supported 16 colours at a time. When the PowerShell team decided they wanted a very specific dark blue as the background colour, rather than altering the colour value for dark or light blue, they instead changed dark magenta to blue and used that as the background colour. I'm not precisely sure why they did this, there's probably some reasoning floating around on the internet somewhere. As a side note, they also changed dark yellow to a light grey and used that as the default foreground for some reason; again, I'm not really sure why.

The end result is that colortool is changing the colours correctly, the problem is simply that PowerShell gets its background colour from a different slot in the colour table.

You can of course fix this yourself by setting the screen background manually in the properties window. As for fixing it in colortool, I'm not sure how or if we should do that. It might be as simple as checking if the parent process is powershell, and if so, setting these registry values to 0x07 (or something similar):

Computer\HKEY_CURRENT_USER\Console\%SystemRoot%_System32_WindowsPowerShell_v1.0_powershell.exe\ScreenColors
Computer\HKEY_CURRENT_USER\Console\%SystemRoot%_SysWOW64_WindowsPowerShell_v1.0_powershell.exe\ScreenColors

But that doesn't take effect until the window is reopened; I'm not sure how to change the screen background for the currently open window.

[wavebeem]

🤔 Very interesting. Thanks for the detailed response.

[parkovski]

Looking at an itermcolors file, this is not quite possible with the current conhost. There are colors 0-15 listed, but there are also separate foreground and background colors, which are not selected from the standard palette. There are others (cursor, cursor text, selection, selected text, and bold) - it'd be nice to have support for setting all of these separately, but top priority for me would be foreground and background. We won't have true itermcolors support until conhost can set those colors independently from the standard 16-color palette.

Compare the screenshot to the ones shown here. In the screenshot in this thread, either the 40m column or the 45m matches the background. That is not the case in any of the screenshots for the link I provided.

The reason I think this should be a priority - when the theme's background color doesn't match the intended one, some text can be really difficult to read.

[flstaats]

The fix is simple and I would love to see the colortool do it automatically.

1. Open a PowerShell windows using the shortcut or command you would normally used.
2. Use the colortool.exe to set the colors (with the -c, -b or -d options as appropriate)
3. In the command window border open right click menu Properties for this instance (or Defaults for the settings for new windows not already associated with a shortcut.)
4. In the colors tab select "Screen Text" and associate with the right most color box (white)
5. In the colors tab select "Screen Background" and associate with the left most color box (black)
6. In the colors tab select "Popup Text" Select the popup text color you want... I choose the default gold
7. In the colors tab select "Popup Background" select the right most color box (white) and save

The default Text and Background colors could and should be selected by the colortool as they are just another registry setting being set. It would be reasonable to optionally not set them with another flag but in most cases where people are using colortool they don't want a bright pink/purple background in their PowerShell windows!!!

Just because the out of the PowerShell selects a non-default color for the background (I've never understood the hard to read choice of dark blue), doesn't mean that the colortool can't be more sensible. I consider the current behavior of making one of the two built in shell programs unreadable to be a major bug.

[parkovski]

That would definitely help, but it still doesn't fix the scenario where a theme defines two similar colors with a separate background color. In iTerm the default background color (same with default foreground) is a different setting than any of the colors settable through escape sequences. The only real fix for this is for the Windows console to also provide totally separate foreground/background color options.

[zadjii-msft]

As you've all mentioned here, essentially, the console doesn't have a separate "Background Color" separate from the color table - it uses one entry of the color table as it's "background color". So if the itermcolors scheme has a different background color from the black color, then the applied scheme is going to look different. It's as close as we can get to what's in the scheme with what conhost can do.

I absolutely want to fix this, but unfortunately its a pretty massive change to the codebase that'd be hard to get signed off on.

I will keep this issue open to track the feature request, hopefully we'll find some time to do it.

[wavebeem]

Understandable. No worries, and thanks for looking into this.

[yatli]

Hello friends,

Will it be acceptable if we calculate the nearest color in a slot to the background, and set the background to that slot?
Also we can apply subtle adjustments to the color scheme itself to keep everything as close to the original as possible.

This is obviously just a workaround but does not need a lot of effort in the backstage. Essentially we are only trying to approximate 18 colors with 16. There's been a vim plugin for approximating a 256 color theme with only 16 colors so I think this approach will definitely work out.

[segevfiner]

Obviously, setting the background color independently of the 16 color palette is the true fix. But that's a change in Window's console that can take a very long time to materialise and land. But before that, there are some improvements that can be made to make colortool quite a workable solution. For starters, it needs to gain the ability to set the background/foreground color index from the 16-color pallete at all. So as to avoid the issue with Powershell, and be able to restore the powershell default theme. I'm not sure if there is a public API for this currently though. Secondly, it needs handling for console settings saved in shortcuts (lnk) files, either by wiping them, or saving settings to them (Preferably as a command that can be used on user created shortcuts in addition to any hardcoded list of default shortcuts). The similar concfg project has a command to wipe them. Third, it needs handling for the multiple saved console settings in the registry. Allowing to set a color scheme globally but maybe even better is a way to list, delete, etc. such settings. For selecting the background/foreground color to set. You can always decide to extend the color scheme files that you use. I don't think you are bound in any way to support some upstream color scheme format exactly. This gives the users the control to adapt a theme to this Windows console limitation in the best way they see rather than trying to guess around that. Guessing/Auto detection can be used for color schemes that don't use such extensions to give a better result still. But that sounds like something you add after the basics work well.

…

On Tue, Feb 13, 2018 at 6:18 AM, Yatao Li ***@***.***> wrote: Hello friends, Will it be acceptable if we calculate the nearest color in a slot to the background, and set the background to that slot? Also we can apply subtle adjustments to the color scheme itself to keep everything as close to the original as possible. This is obviously just a workaround but does not need a lot of effort in the backstage. Essentially we are only trying to approximate 18 colors with 16. There's been a vim plugin for approximating a 256 color theme with only 16 colors so I think this approach will definitely work out. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXlg__rSAUN1-tEiMbE7VZPpeQcJFN8Bks5tUQ0ngaJpZM4PDiaR> .

[zadjii-msft]

0. I'm not going to be able to commit to being able to set the FG/bG independently from the color table. I'd LOVE to implement it, yes, but yea, it's a lot of work.

1. Yes, setting the FG/BG indicies with colortool would be a welcome improvement. Adding entries to the .ini format wouldn't be hard, setting the colors themselves would be easy, and finding the nearest color from a .itermcolors file would be relatively trivial as well. I'd welcome the contribution.

2. Right now, if you use colortool to set the console properties, then open the propsheet and hit okay, they'll persist to the shortcut if you were launched from a shortcut. I'd say that wiping shortcut entries is not really in the scope of the colortool project. I'd rather keep it more focused.

3. That's a bit bigger of an ask, it'd be a pretty major enhancement of our settings infrastructure. Man, if only I had a spec for such a feature, like, maybe sitting in a file share somewhere, ready to implement.... cough @bitcrazed cough

TLDR if someone wants to implement finding the nearest table entry to the itermcolors fg/bg and set the selected fg/bg to that, I'd welcome the PR.

[yatli]

@zadjii-msft there you go: #66

[nickjj]

I'm using the October 2018 release and the background colors are still very much not what they should be. This is also with Microsoft Windows [Version 10.0.17763.134] and the stock ubuntu.exe terminal.

For example, I want to use the Tomorrow scheme which is a light background theme, but ColorTool is using a completely different color scheme than what Tomorrow is defined as in the XML file.

Here's a screenshot of a bunch of schemes I downloaded (just to experiment):

But here's what Tomorrow should look like: https://github.com/mbadolato/iTerm2-Color-Schemes#tomorrow

Any ideas on how to get around this? There's not a single white background scheme that works due to the color tool not loading in the correct colors.

[zadjii-msft]

Could you be more specific? I mean, this looks like it's just fine to me:

Do you mean the "default" foreground and background colors from the itermcolors file? (I think the background is defined under `Background Color

*Nix style terminals support foreground and background colors outside the values from the color table, but conhost doesn't support that unfortunately. With conhost, the fg/bg colors must be an index into the color table, so we ignore those values from the itermcolors file.

Stay tuned in this area - we might have some news soon^tm

[nickjj]

Specifically, with the ubuntu.exe terminal and not modifying anything extra in the Properties:

1. Download https://github.com/mbadolato/iTerm2-Color-Schemes/blob/master/schemes/Tomorrow.itermcolors

2. Place the file into the ColorTool's schemes/ folder

3. Run ./ColorTools -b Tomorrow

4. Open a new terminal

I end up with a black background and the colors do not match the white background that is supposed to show up with the Tomorrow theme. Every single iTerm2 theme listed in that git repo with a white background ends up with a black background.

Is there anything I can change on my end to get the correct foreground and background colors to take effect today using Windows 10 Pro stable (I'm not interested in using insiders)? You must have done something extra to get it to look fine for you.

Edit:

Also, the Solarized light theme that comes with ColorTools properly sets a different background color other than black, without doing anything extra, but I'm unable to understand why that happens but doesn't happen with Tomorrow (or any other white background iTerm theme). Both of them have the same exact keys in the XML file.

[stuaxo]

Suffering in a workplace where I can't download colortool - boo.

Having said that, having a page in the settings where you could choose from colour themes would be a lot nicer than clicking around and editing individual colours.

[zadjii-msft]

@nickjj Up until recently, the Windows Console didn't support "default colors" separate from the rest of the color table. So, if your selected default background color was black before running colortool, it'll still be black after running colortool, just with whatever the new entry for black is.

Even though we've experimentally added support for true terminal-style default colors (in recent Insiders builds), Colortool hasn't yet been updated to add support for them yet.

@stuaxo We definitely feel the pain too, but unfortunately adding support for proper color schemes w/in conhost itself is unfortunately far down our backlog :(. It's just too much work to justify compared to other higher priority work items.

[stuaxo]

Cool, well if it's actually on the backlog that's nice - hopefully it'll arrive one day as a pleasant surprise.

What triggered this is, that at my workplace there is some setup with powershell->docker->??->a bash shell.

Sometimes I'll be in vim editing a file and the foreground and background are the same for some colours:
(unless I'm being colourblind??)

The bit between psql and -c is actually the string $POSTGRES_URL

The setup is all a bit locked down (the shell is launched by divio client, then the file is in another docker-layer). I end up editing the file then cating it to see if it's correct.

Since I'm in some ephemeral container, editing the vim config is tricky ... I assume that if this was running under a terminal like vte I wouldn't have the issue + it probably comes down to limitations in the windows console host.

[Biswa96]

@stuaxo How about this trick? Run the colortool in your PC/Laptop. Export and Copy HKCU\Console registry key to your workplace and import that registry values. Backup your previous registry and ask for permission to change registry before trying this in workplace. Also this is not a "recommend" way.

[stuaxo]

Cheers I'll give that a go on monday. The worst thing about the colourscheme shown is the dark blue with red on top - I just can't read most of the things that appear like that - I assume it's some powershell default ?

[zadjii-msft]

Oh, that's definitely because the powershell background color, the "powershell blue" is actually using the "dark_magenta" table entry.

Powershell's default colors are totally wonky. I'd personally change the properties for your powershell window from having "dark_magenta" as the default background to the "black" entry.

As an example, compare my cmd vs powershell settings:

Cmd on the left has the 0'th index set as my default background, while powershell has the fifth index, which is magenta in cmd, but powershell has overwritten with dark blue.

The "invisible text" that your seeing (or not seeing in this case) is because vim is printing the text in dark_magenta, which doesn't appear against the dark_magenta background.

[stuaxo]

OK, cheers - I'll try this when I get back - I grew up on DOS/Windows but these days Linux is my day-to-day, feels weird going back to Windows (and seeing this console properties box thats been the same since about Windows 3!)