Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color text menus fail if background is white #2451

Closed
prensing opened this issue Oct 2, 2023 · 11 comments
Closed

Color text menus fail if background is white #2451

prensing opened this issue Oct 2, 2023 · 11 comments
Milestone

Comments

@prensing
Copy link

prensing commented Oct 2, 2023

Describe the bug
When using the wacs executable in a CMD window, you cannot read some of the menu entries if the windows is black text/white background. Some of the menu selection letters must be explicitly set to white, so they are unreadable.

To Reproduce

  1. Open CMD window. Set Foreground (text) color to Black and Background to white.
  2. Run wacs.exe.
  3. Some menu items are unreadable.

Expected behavior
For the entries with "default" color, you should be either not specifying any color, or looking up the foreground color and using that.

Platform:

  • OS: Windows Server 2016
@WouterTinus
Copy link
Member

This is a issue with any use of color in the app. For someone with a green background, the green text wouldn't be visibile, etc. The quickest/safest way to work around this would be to force the background to be black for everyone. Unfortunatly there doesn't seem to be a straightforward way to force or detect the background color in all consoles (e.g. Powershell, cmd, Windows Terminal, etc.)

At least in Windows Terminal (which I prefer myself) if I pick a black-on-white color scheme, the .NET API Console.BackgroundColor doesn't reflect this at all. And even if I specifically ask for a black background, it's not applied on the screen, so at some level it's re-mapping colors in a way that's not visible to the app.

I guess one alternatively there could be to offer different color schemes to pick from, but that seems a bit excessive for a tool that's mostly meant for automation. So perhaps a monochrome mode would be the optimal solution.

@prensing
Copy link
Author

prensing commented Oct 3, 2023

I understand and agree with you, in that it is a lot of effort to support any arbitrary color scheme, and probably not worth it. OTOH, the only text that disappeared was a few of the selection letters at the front of lines; the actual text was all readable. I assume that means you set the color for the selection letters, but use default colors for the explanations.

I suggest that you only force the color for the highlighted entries, and use defaults for the "normal" ones. That would have solved it in my case. Or, maybe, you could set the background as well as foreground color (I assume that is doable); it would look weird, but would be readable.

Thanks for the effort. So far, a good tool!

@WouterTinus
Copy link
Member

I suggest that you only force the color for the highlighted entries, and use defaults for the "normal" ones. That would have solved it in my case.

Yes, that would solve your case but not the general problem of using colors in the TUI vs. an infinite number of possible user terminal settings, hence my proposal for a monochrome setting (default colors only).

Or, maybe, you could set the background as well as foreground color (I assume that is doable); it would look weird, but would be readable.

I tried this, but the terminal ignores the black background color completely (or rather it treats my request for "black" as "whatever the user chose". But while it happily remaps black to white, it doesn't have the sense to do it vice versa as well, which breaks the UI in this case. With a blue/red/whatever background it does respect the color that the app requests, but that doesn't look pretty at all.

I also tried making everything have a dark blue or dark gray background to avoid the remapping issue that black seems to be cursed with, but the logging library messes that up. So I still think monochrome is the way to go.

@WouterTinus WouterTinus added this to the 2.2.7 milestone Oct 4, 2023
@WouterTinus
Copy link
Member

I found a way to force a black background using vt100 escape codes, so that will be implemented in the next release.

@RichardHowells
Copy link

Whoa! That must have been a history (or even archaeological) lesson!

@WouterTinus
Copy link
Member

Actually there quite a few console app widget libraries, so I dug through their sources to figure out how they do it :)

@WouterTinus
Copy link
Member

Fixed in 2.2.7!

@MrGadget1024
Copy link

So this is the PR that broke my UI :(

image

@WouterTinus
Copy link
Member

See #2513. But as stated there too, Windows 2012 is no longer supported by Microsoft so you can expect more stuff to start failing over time. Upgrade as soon as you can.

@MrGadget1024
Copy link

@WouterTinus Saw it and working on migrating everything to our new 2022 win server. I suspect you're about to find out how many users are on old servers! :)

Thanks for all your work!

@WouterTinus
Copy link
Member

This feature has been disabled by default in 2.2.7.1 - it can be re-enabled in settings.json by setting UI.Color.Background to "black"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants