Text is completely invisible on common light terminal configurations

[chris-morgan]

It’s very common on light terminals for white to match the default background colour exactly. As it stands, bluetuith uses bold white (␛[37;1m). This means that, in terminals like mine, almost all of the text is invisible, and the entire output of bluetuith --help.

If you’re going to default to using foreground colours like black or white, you must also set a contrasting background colour.

The vastly preferable option is not using black or white. As far as I can tell, all the places bluetuith is using bold white should be just default colour (that is, drop the ␛[37m), and almost always not bold, either (that is, drop the ␛[1m). Certainly bluetuith --help has no business setting colours.

More generally, if you’re going colouring things, here’s my advice, independent of project. I recommend that a default theme use only these styles: the default foreground and background colours; foreground colours 1, 2, 5 and 6; bold for emphasis; uncoloured invert for emphasis; and faint, italic and underline as optional enhancements which not all terminals will support. Black and white are verboten (they might each be maximum or zero contrast). Blue is somewhat risky (because of mostly-historical-but-definitely-not-entirely-gone dark themes). Yellow is fine, but bright yellow is very risky (because of light themes), so bold yellow becomes risky as it may become bright. Background colours are moderately risky, must not be used without specifying a foreground colour, and should not be used for large areas. Invert with non-default colours is generally unwise. Bright colours (8–15) are a little risky because in light themes they can be higher contrast (darker) or higher intensity (lighter). Really, the 16-colour thing is just fundamentally a very bad design that made assumptions that were never correct.

Another remark, the stuff exposed in --theme is strange and limiting. It doesn’t let you remove colours (default colour!) or styles like bold, or specify colour numbers (0–255) which is commonly preferable and likely to be much clearer.

_{Extra keyword for search purposes: color.}

[darkhz]

Thank you for your detailed analysis and advice.

I agree, the theming aspect needs to be completely reworked.

I have implemented dynamic theming for another project (https://github.com/darkhz/invidtui/tree/theme), wherein:

• The theme configuration is more verbose
• Styles and colors can be tuned individually for different elements, (like default text, background, status bar etc.)
• Themes can be changed without restarting the app.

This is currently being tested, and can be imported once I have finished testing it.

Documentation is sparse, but do look at the default configuration here, which has brief documentation: https://github.com/darkhz/invidtui/blob/theme/themes/default.theme Suggestions related to the theming format and application are most welcome.

EDIT:

• If possible, could you record a small video highlighting the issue?
• And, it would be nice if you could list your preferred theme/color application for the elements, like background, foreground and text, in a brief format, so that I can make a checklist.

[txgk]

Hi, just wanted to help out a little.

Here's the kitty with Solarized Light:

(looks fine to me)

Here's the alacritty with Gruvbox Dark:

(i think white is mixed up a little with the green and magenta)

Here's the alacritty with GitHub Light:

(colors are mixed up with the grey)

Here's the kitty with Tango Dark:

(looks good)

I'm on bluetuith-0.2.2_1 package on Void Linux, btw

[darkhz]

@txgk very helpful, thank you so much. I'm looking into it, although this will be fixed much later, due to the work on other more priority based tasks on the application.

I also plan to make the theme engine load themes dynamically, have to port the theme engine from invidtui and maybe modify it, but this will make customising all elements more granular.

[frankier]

This is foot on sway with defaults