Directory names hard to read in default color scheme #191

darksky commented 2022年03月07日 15:50:15 +01:00 (Migrated from code.blicky.net)

I am finding the hilight line of version 2.1 with either dark or dark-bg to be very intense to my eye. It appears bright green in my xterm and makes reading the directory name which appears in blue very difficult.

Please consider adding a config file setting to allow users to define the highlight color.

I am finding the hilight line of version 2.1 with either `dark` or `dark-bg` to be very intense to my eye. It appears bright green in my xterm and makes reading the directory name which appears in blue very difficult. Please consider adding a config file setting to allow users to define the highlight color.

yorhel commented 2022年03月15日 15:13:03 +01:00 (Migrated from code.blicky.net)

Meh. You're not the first to take issue with the colors, and you're right that it doesn't display well in all terminals. I really don't see why anyone would spend time theming a disk usage analyzer they (probably) won't use every day, so I'm hesitant to bloat ncdu with even more config options. I'd much rather fix the default colors to be more readable in all terminals. Color suggestions welcome.

Meh. You're not the first to take issue with the colors, and you're right that it doesn't display well in all terminals. I really don't see why anyone would spend time theming a disk usage analyzer they (probably) won't use every day, so I'm hesitant to bloat ncdu with even more config options. I'd much rather fix the default colors to be more readable in all terminals. Color suggestions welcome.

darksky commented 2022年03月18日 10:41:28 +01:00 (Migrated from code.blicky.net)

Can you point me to documentation that lists the available color names? Initially, just changing all instances of COLOR_GREEN to COLOR_BLUE within src/ui.zig seems much nicers on my xterm (xfce4-xterm).

I am not use how to access another color the palette calls "dark gray" to test it out (bottom left color in attachment).

Can you point me to documentation that lists the available color names? Initially, just changing all instances of `COLOR_GREEN` to `COLOR_BLUE` within `src/ui.zig` seems much nicers on my xterm (xfce4-xterm). I am not use how to access another color the palette calls "dark gray" to test it out (bottom left color in attachment).

yorhel commented 2022年03月18日 11:34:24 +01:00 (Migrated from code.blicky.net)

Only the top 8 colors can be used as background, they're named as follows:

COLOR_BLACK
COLOR_RED
COLOR_GREEN
COLOR_YELLOW
COLOR_BLUE
COLOR_MAGENTA
COLOR_CYAN
COLOR_WHITE

The bottom colors are only usable as text color, and typically selected when A_BOLD is used (though libvte-based terminals and perhaps others have that "bold is bright" checkbox disabled by default nowadays, so that makes things even more annoying).

I've tested all backgrounds on BLUE text and can only conclude that none of them have great contrast. BLUE on BLUE as you suggest is probably invisible if you disable the "bold is bright" checkbox.

I think the only sane alternative (without switching to less portable color modes) is to change the text color for dirs. Haven't really experimented with that yet.

Only the top 8 colors can be used as background, they're named as follows: ``` COLOR_BLACK COLOR_RED COLOR_GREEN COLOR_YELLOW COLOR_BLUE COLOR_MAGENTA COLOR_CYAN COLOR_WHITE ``` The bottom colors are only usable as text color, and typically selected when `A_BOLD` is used (though libvte-based terminals and perhaps others have that "bold is bright" checkbox disabled by default nowadays, so that makes things even more annoying). I've tested all backgrounds on BLUE text and can only conclude that none of them have great contrast. BLUE on BLUE as you suggest is probably invisible if you disable the "bold is bright" checkbox. I think the only sane alternative (without switching to less portable color modes) is to change the text color for dirs. Haven't really experimented with that yet.

darksky commented 2022年03月18日 12:58:05 +01:00 (Migrated from code.blicky.net)

OK. Didn't realize there are differences in how different xterm clients render thing. Pity. For my specific use case, I think I will just patch your source with the /COLOR_GREEN/COLOR_BLUE/ in src/ui.zig and call it good. Probably safe to close this issue.

OK. Didn't realize there are differences in how different xterm clients render thing. Pity. For my specific use case, I think I will just patch your source with the `/COLOR_GREEN/COLOR_BLUE/` in `src/ui.zig` and call it good. Probably safe to close this issue.

darksky commented 2022年03月25日 21:59:08 +01:00 (Migrated from code.blicky.net)

I don't know how general the blue for green substitution is, but it is MUCH more readable on my systems. Consider changing it?

I don't know how general the blue for green substitution is, but it is MUCH more readable on my systems. Consider changing it?

dicktyr commented 2022年05月16日 06:35:55 +02:00 (Migrated from code.blicky.net)

it seems you're constrained to a specific pallette
but a good rule of thumb to remember

use only just enough emphasis, not too much

the current line is easy to see as it responds to user input
so it needs even less emphasis

I'd suggest ever so slightly lighter for the dark background
and ever so slightly darker for the light background

in any case
thank you very much for ncdu!

it seems you're constrained to a specific pallette but a good rule of thumb to remember *use only just enough emphasis, not too much* the current line is easy to see as it responds to user input so it needs even less emphasis I'd suggest ever so slightly lighter for the dark background and ever so slightly darker for the light background in any case thank you very much for ncdu!

score commented 2022年05月17日 02:24:14 +02:00 (Migrated from code.blicky.net)

I have a slightly customised pastel terminal colour scheme (nothing too out-there, but it makes many applications like htop much less visually grating). While some colours do clash in ncdu, the complaint I have is that I cannot read the total disk usage in the status bar and have to paste it into another application.

Echoing the above I would suggest using darker colours in the status bar, and since most of the text in the main view of the application is light, the selection background should be of a darker colour. The human eye tends to register green much brighter than the other primary colours, so perhaps red would be a better option here, or a windowsy blue coupled with a recolour of the file paths.

I have presented an alternative colour scheme in the second uploaded screenshot with the above mentioned tweaks applied. I can sympathise if you're frustrated that the subtle windows-ification of the colour scheme makes it a little less unique!

The patch, if it's of interest, is also attached.

Finally, I have also attached a pair of screenshots from the vte-based Sakura terminal with the bold-as-bright switch off and on respectively.

I have a slightly customised pastel terminal colour scheme (nothing too out-there, but it makes many applications like htop much less visually grating). While some colours do clash in ncdu, the complaint I have is that I cannot read the total disk usage in the status bar and have to paste it into another application. Echoing the above I would suggest using darker colours in the status bar, and since most of the text in the main view of the application is light, the selection background should be of a darker colour. The human eye tends to register green much brighter than the other primary colours, so perhaps red would be a better option here, or a windowsy blue coupled with a recolour of the file paths. I have presented an alternative colour scheme in the second uploaded screenshot with the above mentioned tweaks applied. I can sympathise if you're frustrated that the subtle windows-ification of the colour scheme makes it a little less unique! The patch, if it's of interest, is also attached. Finally, I have also attached a pair of screenshots from the vte-based Sakura terminal with the bold-as-bright switch off and on respectively.

dicktyr commented 2022年05月17日 05:44:22 +02:00 (Migrated from code.blicky.net)

the status bar

good point
and the same issue in the top line

I suggest removing the background for both
or at least reducing the emphasis

> the status bar good point and the same issue in the top line I suggest removing the background for both or at least reducing the emphasis

yorhel commented 2022年05月17日 09:40:00 +02:00 (Migrated from code.blicky.net)

I can sympathise if you're frustrated that the subtle windows-ification of the colour scheme makes it a little less unique!

No, I'm frustrated that the basic terminal color palette is broken to the point of uselessness. How is one supposed to use develop applications when no color combination is readable for everyone? I'm almost inclined to go back to B/W by default.

I have no sense of design and even the current color scheme was contributed, so I'm not very picky. I do dislike too much churn, though, as that just invites more complaints and bikeshedding.

I have presented an alternative colour scheme

Looks okay, with 2 nitpicks: the distinction between dirs and files is barely visible now with bold-is-bright disabled, and I feel that using red for numbers signals that there's something wrong with them, but that could be just me.

Anyway, looks like a step in the right direction.

> I can sympathise if you're frustrated that the subtle windows-ification of the colour scheme makes it a little less unique! No, I'm frustrated that the basic terminal color palette is broken to the point of uselessness. How is one supposed to use develop applications when no color combination is readable for everyone? I'm almost inclined to go back to B/W by default. I have no sense of design and even the current color scheme was contributed, so I'm not very picky. I do dislike too much churn, though, as that just invites more complaints and bikeshedding. > I have presented an alternative colour scheme Looks okay, with 2 nitpicks: the distinction between dirs and files is barely visible now with bold-is-bright disabled, and I feel that using red for numbers signals that there's something wrong with them, but that could be just me. Anyway, looks like a step in the right direction.

yahono commented 2023年01月08日 20:21:37 +01:00 (Migrated from code.blicky.net)

@yorhel I would like to cast a vote for @score's solution. I agree it's a step in the right direction.

An even simpler solution may be to take a page from htop. Headers, footers, and currently highlighted items would be displayed as black text on a color background.

This would preserve what's already working well colorwise, namely file/directory and column distinction, and also fix current contrast issues for all terminals.

@yorhel I would like to cast a vote for @score's solution. I agree it's a step in the right direction. An even simpler solution may be to take a page from `htop`. Headers, footers, and currently highlighted items would be displayed as black text on a color background. This would preserve what's already working well colorwise, namely file/directory and column distinction, and also fix current contrast issues for all terminals.

AndyKluger commented 2026年01月22日 20:29:42 +01:00 (Migrated from code.blicky.net)

As far as I can tell, all the illegible parts of the UI are limited to a subset of the only three lines with a special background: current folder/file line, the version/help line at the top, and the info line at the bottom.

Could the problem be solved by either one of:

• don't use a special background anywhere (for the current folder/file line, a glyph such as ▶ could appear)
• for all three special background cases, use a color that is very nearly the same as the main background color

?

I guess that second option departs from the 8-color restriction.

As far as I can tell, all the illegible parts of the UI are limited to a subset of the only three lines with a special background: current folder/file line, the version/help line at the top, and the info line at the bottom. Could the problem be solved by either one of: - don't use a special background anywhere (for the current folder/file line, a glyph such as `▶` could appear) - for all three special background cases, use a color that is very nearly the same as the main background color ? I guess that second option departs from the 8-color restriction.