WIP: Colors: Add ansi_default and make ansi_* colors actually output their ansi sequences #1460
Conversation
|
We don't intend to support the 16 ansi colors, because they make it impossible to guarantee a consistent UI on all platforms. If you rely on a user's selection, them some color combinations will always look bad for some users. |
|
I mostly just want to support a default background color. I enjoy terminal-based applications because I use a semi-transparent terminal window and I like to see my desktop background. The textual application I'm developing has no big use for color. If we don't go ahead with this, maybe we could instead use a environment variable to disable colors (or to downgrade to ANSI colors), like Textualize/rich#2449 ? I've always been a guy to customize my terminal's color-scheme, so using the ANSI colors seemed like a natural way to give more consistency to the users, as their terminal emulator has configured the colors already to a palette they're used to. Application developers who want conformity in their app's appearance could just use the non |
| if rich_color.type is ColorType.STANDARD: | ||
| return cls(r, g, b, math.nan) | ||
| elif rich_color.type is ColorType.DEFAULT: | ||
| return cls(1, 1, 1, math.nan) |
There was a problem hiding this comment.
(I think this might be the controversial change from this PR, as a lot of rich color names are made into ansi colors)
Textual supports all of the env vars that Rich does. Supporting ansi colors isn't going to happen, sorry. It makes it impossible to guarantee an app will have a usable color scheme on all platforms. It might make some users happy, but we will be flooded with issues that users can't see cyan on black. Or that yellow looks too much like green. I know this from 3 years of Rich issues. If we made it optional it would be a performance hit, and we would get issues that ansi colors don't work with opacity and alpha blending. The Textual color system will eventually be themeable, which means we can guarantee it will look good on all platforms. You will also be able to match it with your ansi color theme, and still have opacity and alpha blending, plus multiple shades. I understand you like your ansi theme, and have carefully picked one to your liking. I do to. But ansi colors are predicated on 1970s VDU technology. Supporting them would hold Textual back for little benefit. |
This argument makes sense (or course barring the platforms which only support default + the 16 ansi colors like many framebuffer terminal emulators).
Yeah, looking at the past issues, that's probably true (even if we tried to make it clear in the documentation that
Yeah, personally I guess I don't care about the ansi colors for my use-case, but I do care about Here's my (rough, WIP) app, both with the default background color, and with A couple things to note:
Would a separate PR implementing just ansi_default be considered (assuming those two points are taken care of)? |
|
Scrollbars also need to be changed to not be inverted. It would be really great to use https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing, as they provide the "right" and "upper" blocks that Block Elements leave out, but they look bad, at least in the fonts that I have :( |
…f inverting fg/bg colors
|
"Symbols for Legacy Computing" is a relatively new block (Unicode 13.0 in 2020), so it will be a while until they catch on with fonts. (It was clearly designed to fill out the missing "Block Elements"
|
Please review the following checklist.