Colors in Default MacOS Terminal profile (Black on White) looks kind of broken #203

Thommy commented 2022年06月06日 11:28:11 +02:00 (Migrated from code.blicky.net)

You can see on the following picture ncdu 1.x on the top, ncdu 2.x on the bottom.
The left images are using default Black on White color profile on MacOS, and ncdu.2x looks horrible with it.

The right images are using Homebrew profile which I picked just as example of black backgrounded profile in which it looks OK.

image

You can see on the following picture ncdu 1.x on the top, ncdu 2.x on the bottom. The left images are using default Black on White color profile on MacOS, and ncdu.2x looks horrible with it. The right images are using Homebrew profile which I picked just as example of black backgrounded profile in which it looks OK. 

yorhel commented 2022年06月15日 06:29:25 +02:00 (Migrated from code.blicky.net)

The background issue has been fixed with #204. Readability of the actual colors is being discussed in #191.

The background issue has been fixed with #204. Readability of the actual colors is being discussed in #191.

chris-morgan commented 2022年10月10日 16:51:57 +02:00 (Migrated from code.blicky.net)

Note that in these sorts of terminal themes, --color dark works just fine, because it’s not actually a dark colour scheme, but quite generic and neutral.

Sure, dark-bg was flawed in not setting the global background, but the real fix is to switch the default from dark-bg to dark, which doesn’t try setting the background at all. dark-bg is just the wrong approach philosophically for almost all terminal configurations.

Note that in these sorts of terminal themes, `--color dark` works just fine, because it’s *not* actually a dark colour scheme, but quite generic and neutral. Sure, dark-bg was flawed in not setting the global background, but the real fix is to switch the default from dark-bg to dark, which doesn’t try setting the background at all. dark-bg is just the wrong approach philosophically for almost all terminal configurations.

yorhel commented 2022年10月10日 17:11:43 +02:00 (Migrated from code.blicky.net)

I would agree if there was a way to detect black-on-white terminal configurations, because in those cases the 'dark' color scheme is largely unreadable. And "unreadable" is sadly not a good default. :(

I would agree if there was a way to detect black-on-white terminal configurations, because in those cases the 'dark' color scheme is largely unreadable. And "unreadable" is sadly not a good default. :(

chris-morgan commented 2022年10月10日 17:38:25 +02:00 (Migrated from code.blicky.net)

I use a light terminal. I joyfully use --color dark; it’s completely fine. (--color dark-bg, if it did truly set a black background all over as I suppose #204 achieves, would incense me.) The green background for the selected row is a bit garish, but that’s nothing to do with light versus dark (and that’s much of the subject of #191). There are a few minor places where you use the colour codes for black and white, which in a light theme could each be black or white (some are literal, which is how I wrote mine, and have black be black and white be white; others flip it around, following contrasts, so that black is white and white is black—my vague recollection is that macOS’s Terminal.app default is a flipped one), but the damage in a flipped theme still won’t be too significant—in fact, the header and footer bars may well become more legible.

I use a light terminal. I joyfully use `--color dark`; it’s completely fine. (`--color dark-bg`, if it did truly set a black background all over as I suppose #204 achieves, would incense me.) The green background for the selected row is a bit garish, but that’s nothing to do with light versus dark (and that’s much of the subject of #191). There are a few minor places where you use the colour codes for black and white, which in a light theme could each be black or white (some are literal, which is how I wrote mine, and have black be black and white be white; others flip it around, following *contrasts*, so that black is white and white is black—my vague recollection is that macOS’s Terminal.app default is a flipped one), but the damage in a flipped theme still won’t be *too* significant—in fact, the header and footer bars may well become more legible.

yorhel commented 2022年10月10日 17:48:12 +02:00 (Migrated from code.blicky.net)

I'm glad Temrinal.app has a sensible color pallete, in xterm the yellow is pretty much unreadable.

would incense me

I mean, you can always change the default.

I'm glad Temrinal.app has a sensible color pallete, in xterm the yellow is pretty much unreadable. > would incense me I mean, you can always change the default.

chris-morgan commented 2022年10月10日 18:40:51 +02:00 (Migrated from code.blicky.net)

And in various dark terminals, blue is pretty much unreadable. In both cases, these are largely legacy concerns that will affect few users: we’ve almost reached the stage where only unmaintained terminal emulators have such bad defaults, and using such tools is increasingly likely to be a conscious choice, by people who have Opinions on How Things Should Be and who are much more likely to change the colours to suit their foibles and sensibilities.

Incidentally, that’s bright yellow, triggered by the (mildly surprising) use of bold. If bold were not used, you’d get a much more legible yellow. XTerm probably allows you to disable the bold-implies-bright thing (which incidentally has also been falling out of favour as a default across the board), though I’m not sure. (Further aside: I spoke of potentially-flipped black and white in light terminals, but there’s another such thing: are colours 8–15 brighter/lighter, or are they higher contrast (which implies darker to at least some extent)?

The fact of the matter is that if you really care about compatibility and readability in terminals, you avoid yellow and blue. And black and white. And high-intensity colours. And changing background colours. So that in practice you have about five foreground colours only: default, red, green, magenta, cyan. Seriously. It’s that bad. OK, so non-bright yellow is probably OK, and bright blue is likely to be a little better, and some of the bright colours are likely to be OK, so if you’re feeling adventurous you can get up to about nine of the seventeen foreground colours available in your 16-colour terminal.

And in various *dark* terminals, *blue* is pretty much unreadable. In both cases, these are largely legacy concerns that will affect few users: we’ve *almost* reached the stage where only unmaintained terminal emulators have such bad defaults, and using such tools is increasingly likely to be a conscious choice, by people who have Opinions on How Things Should Be and who are much more likely to change the colours to suit their foibles and sensibilities. Incidentally, that’s *bright* yellow, triggered by the (mildly surprising) use of bold. If bold were not used, you’d get a much more legible yellow. XTerm probably allows you to disable the bold-implies-bright thing (which incidentally has also been falling out of favour as a default across the board), though I’m not sure. (Further aside: I spoke of potentially-flipped black and white in light terminals, but there’s another such thing: are colours 8–15 *brighter/lighter*, or are they *higher contrast* (which implies darker to at least some extent)? The fact of the matter is that if you *really* care about compatibility and readability in terminals, you avoid yellow and blue. And black and white. And high-intensity colours. And changing background colours. So that in practice you have about five foreground colours only: default, red, green, magenta, cyan. Seriously. It’s that bad. OK, so non-bright yellow is *probably* OK, and bright blue is likely to be a *little* better, and some of the bright colours are likely to be OK, so if you’re feeling adventurous you can get up to about nine of the seventeen foreground colours available in your 16-colour terminal.

yorhel commented 2022年10月10日 19:41:36 +02:00 (Migrated from code.blicky.net)

I mean, I really do care about having defaults that work in all scenarios, ncdu is a tool that ought to just workTM when and where you need it. Hence my attempt at introducing colors through the ugly dark-bg scheme. I get that you didn't intend it this way, but what you're really saying is that my attempt was doomed from the start and going forward I should either try and create a new color scheme with your suggested colors, or go back to disabling colors by default. The latter has been on my mind for a while and seems to be the most sane way out of this.

I mean, I really do care about having defaults that work in all scenarios, ncdu is a tool that ought to just workTM when and where you need it. Hence my attempt at introducing colors through the ugly dark-bg scheme. I get that you didn't intend it this way, but what you're really saying is that my attempt was doomed from the start and going forward I should either try and create a new color scheme with your suggested colors, or go back to disabling colors by default. The latter has been on my mind for a while and seems to be the most sane way out of this.

chris-morgan commented 2022年10月11日 07:59:46 +02:00 (Migrated from code.blicky.net)

I think dark-bg is very much the wrong balance for Just Working. Ignoring the matter of the green background for the selected item (which affects both themes), dark works well for most people, and badly for a very few users in a couple of places (and the more drastic of these is fairly easily fixed by unbolding the yellow text). But dark-bg doesn’t fix all the problems (it introduces new inconsistencies because of the existence of flipped black/white and intensity/contrast themes), and introduces a legitimately extreme usability penalty on light terminal users. Terminal colour schemes (light and dark alike) are generally set up in such a way that you can’t just invert the default background/foreground, because the colours were chosen for their contrast with one end of the spectrum, not the other. Thus, forcing light background on a dark terminal, and forcing a dark background on a light terminal, are both wrong and will produce genuinely painful results for some users in some lighting conditions. Picture how in dim lighting you might want to turn down the brightness of your screen when you switch from dark-background to light-background content; it’s the same in reverse. Not only is the change highly disconcerting, it messes with your eyes and your monitor brightness.

Thus I say: tools like this should never default to setting a global background colour.

dark is extremely bad for a very few users.

dark-bg is very bad for a few users, and bad for many users.

Of the two, assuming no other changes, I think dark is the more sensible default; and with a few more tweaks it can be made even more conclusively the better option. But perhaps off is indeed the better default for now.

I think `dark-bg` is very much the wrong balance for Just Working. Ignoring the matter of the green background for the selected item (which affects both themes), `dark` works well for most people, and badly for a *very* few users in a couple of places (and the more drastic of these is fairly easily fixed by unbolding the yellow text). But `dark-bg` doesn’t fix all the problems (it introduces new inconsistencies because of the existence of flipped black/white and intensity/contrast themes), and introduces a legitimately *extreme* usability penalty on light terminal users. Terminal colour schemes (light and dark alike) are generally set up in such a way that you can’t just invert the default background/foreground, because the colours were chosen for their contrast with one end of the spectrum, not the other. Thus, forcing light background on a dark terminal, and forcing a dark background on a light terminal, are both wrong and will produce genuinely painful results for some users in some lighting conditions. Picture how in dim lighting you might want to turn down the brightness of your screen when you switch from dark-background to light-background content; it’s the same in reverse. Not only is the change highly disconcerting, it messes with your eyes and your monitor brightness. Thus I say: tools like this should *never* default to setting a global background colour. `dark` is extremely bad for a very few users. `dark-bg` is very bad for a few users, and bad for many users. Of the two, assuming no other changes, I think `dark` is the more sensible default; and with a few more tweaks it can be made even more conclusively the better option. But perhaps `off` is indeed the better default for now.