|
|
Log in / Subscribe / Register

Refreshing

Refreshing

Posted Jun 9, 2021 20:51 UTC (Wed) by khim (subscriber, #9252)
In reply to: Refreshing by nix
Parent article: Rewriting the GNU Coreutils in Rust

You have made me really curious.

Specifically that:
> nearly-unreadable ultra-low-contrast dark blue on black

And of course what I have find is something which is really well-readable and nice looking. While yellow used for README.md and Makefile is a bit hard for me to read (but not hard enough to declare them not usable).

Finding good colors is hard. People are different and significant percentage of males have issues there. Thus I'm not sure “oh, default colors don't look nice to me — means the whole project is unsuitable for everyone” is a good attitude.

> but the whole point of exa is to make better decisions by default

But what is “better decisions by default”? We may aim to create better peception for the majority of people (the ones with no defects) or we may try to make sure our color scheme is poor-but-acceptable for most people (including the ones with vision defects). My guess would be that ls and axe aim for the 1st (which makes sense for highly-configurable tool) while web sites are usually designed for the 2nd.

This creates strange dilemma: colors which are best for actual program are not best for the website dedicated to that program… so what should be done about that? Should the website use some non-standard palette to make it acceptable for the majority or use the actual default colors program uses? I don't think these are easy decisions and I don't think exa is big enough project to afford market research…


to post comments

Refreshing

Posted Jun 10, 2021 1:07 UTC (Thu) by kschendel (subscriber, #20465) [Link] (4 responses)

After periodically fiddling with various color schemes for ls and other tools over the years, I've decided that the best color scheme is white on black - at least for me. (and I have no color deficiencies in my vision.) I find that either the colors don't really add any value, or they work sometimes and not others depending on what it is I'm interested in at the moment.

So I guess I have no objection to the (rather peculiar IMO) colors shown on the exa website as long as I can turn it all off and just see black and white.

Refreshing

Posted Jun 10, 2021 2:00 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

In theory, most tools should be smart enough to completely disable color when TERM=dumb. Unfortunately, it seems that GNU ls (with --color=auto) just checks isatty and assumes that all reasonable ttys can support at least 16 colors (which is probably a fair assumption these days, but IMHO "dumb" means "no really, I can't do anything other than clearing the screen, don't try to get clever with me" rather than "just assume I'm a vt100 or whatever"). I have not tried exa.

Refreshing

Posted Jun 24, 2021 12:53 UTC (Thu) by immibis (subscriber, #105511) [Link] (2 responses)

> but IMHO "dumb" means "no really, I can't do anything other than clearing the screen, don't try to get clever with me" rather than "just assume I'm a vt100 or whatever"). I have not tried exa.

Surely "dumb" means "I can't do anything other than printing characters - not even clearing the screen"?

Refreshing

Posted Jun 24, 2021 15:50 UTC (Thu) by james (guest, #1325) [Link] (1 responses)

AIX login assumes you can clear any screen with enough linefeeds.

Refreshing

Posted Jun 28, 2021 13:56 UTC (Mon) by immibis (subscriber, #105511) [Link]

Sounds like a waste of paper :)

Refreshing

Posted Jun 10, 2021 11:26 UTC (Thu) by jengelh (subscriber, #33263) [Link] (1 responses)

>Finding good colors is hard

Yes, it's hard if you try to give a color to every thing under the sun, which leads to a bad tutti-frutti overload like mcedit[1].
No, it's not that hard:
As an application developer, firstly, make colors the user's business and emit as few as possible by default. My recommendation is to do with just {default_fg, fg_hue1_shade1, fg_hue1_shade} and {default_bg}. Such reduced color sets[2] vastly facilitate the user switching between x-on-black and x-on-white and hue1-on-x and hue2-on-x to facilitate room lighting and mood.

[1] https://paste.opensuse.org/view/raw/21792273 (mcedit with 7+ colors, 11+ shades, not all pictured / background never counted)
[2] https://paste.opensuse.org/view/raw/73371546 (2c3s)

Refreshing

Posted Jun 10, 2021 12:07 UTC (Thu) by khim (subscriber, #9252) [Link]

> Yes, it's hard if you try to give a color to every thing under the sun, which leads to a bad tutti-frutti overload like mcedit.

Surely you jest? I'm using mcedit more often than not because I like how it colors things. There are many things I don't like about mcedit (e.g. I really hate that a single long line can slow down it immensely), but colors? Mcedit is one if the best examples IMO. At least for me.

> As an application developer, firstly, make colors the user's business and emit as few as possible by default.

Nope. That's 2nd step. You have omitted extremely important 1st step: accept that you are not developing program which you would like to use in it's default configuration and create program for “someone else”. Maybe even conduct some kind of “UI research” (like GNOME guys did before they developed GNOME 3).

Unfortunately, considering the end result of GNOME3 redesign, I couldn't say that's the road to success.

And if you skip that 1st step and create something which you, personally, would like to use… is that really such an awful sin? Git was created that way, after all. And it's wildly more successful than GNOME3.

> Such reduced color sets[2] vastly facilitate the user switching between x-on-black and x-on-white and hue1-on-x and hue2-on-x to facilitate room lighting and mood.

Indeed. It makes it possible to do something which I never need or want. But why should developer value that ability higher than the ability to do what they need or want?

You somehow skipped that part entirely.

P.S. And I'm all too ready to admit that my tastes may be “wrong”. Perhaps lasting impression of Norton Commander and Turbo Pascal have left it's mark, who knows. But when I hear “color support is not hard, you just need to avoid this <link to something I like> and do this <link to something I hate>” then only reaction it may evict in me is “who died and make your god?” and/or “why should I create the program which you would like and not I would like?” People are different. Deal with this.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds