Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 483976 - app-portage/eix-0.29.3 background color default inappropriate for Konsole black-on-white
Summary: app-portage/eix-0.29.3 background color default inappropriate for Konsole bla...
Status: RESOLVED DUPLICATE of bug 438076
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Martin Väth
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-06 11:56 UTC by Joe Breuer
Modified: 2013-09-14 13:15 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Screenshot showing the new default colors (eix-default.png,41.15 KB, image/png)
2013-09-06 11:56 UTC, Joe Breuer
Details
Screenshot showing the SOLARIZED color scheme (eix-solarized.png,21.72 KB, image/png)
2013-09-06 11:56 UTC, Joe Breuer
Details
Screenshot showing the colors with BG3=none (eix-bg3none.png,23.58 KB, image/png)
2013-09-06 11:57 UTC, Joe Breuer
Details
Screenshot showing the colors of eix before the update (eix-before.png,20.30 KB, image/png)
2013-09-06 11:57 UTC, Joe Breuer
Details
Screenshot showing emerge's colors (emerge-colors.png,197.02 KB, image/png)
2013-09-06 12:01 UTC, Joe Breuer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Breuer 2013-09-06 11:56:10 UTC
I got app-portage/eix-0.29.3 with my last world update.

I use Konsole (2.10.5 in KDE 4.10.5) with a black-on-white color scheme; it sets TERM=xterm and COLORFGBG=0;15.

There is no explicit configuration in /etc/eixrc/* or ~/.eixrc.

Since this new version, all output of eix shows up with a medium-gray background - that's quite irritating and hard to read.
AFAIK the "intense" option is turned on for the background; something that IMO should not be done for non-markup background.
This is shown in eix-default.png.


a) Setting 'SOLARIZED' to 'true' in eixrc gives "background is not changed, foreground is quite bright and bold". I'll attach eix-solarized.png.

b) Setting 'BG3' to 'none' gives visually pleasing output (background unchanged from terminal default, fg suitable for display on bright background); but with a completely different color scheme from earlier eix and the portage/gentoolkit tools. I'll attach eix-bg3none.png.

The output of earlier versions of eix is shown in eix-before.png


IMO, the background color of non-marked-up output should never be changed - at least with default/empty configuration.
Comment 1 Joe Breuer 2013-09-06 11:56:32 UTC
Created attachment 358038 [details]
Screenshot showing the new default colors
Comment 2 Joe Breuer 2013-09-06 11:56:56 UTC
Created attachment 358040 [details]
Screenshot showing the SOLARIZED color scheme
Comment 3 Joe Breuer 2013-09-06 11:57:16 UTC
Created attachment 358042 [details]
Screenshot showing the colors with BG3=none
Comment 4 Joe Breuer 2013-09-06 11:57:41 UTC
Created attachment 358044 [details]
Screenshot showing the colors of eix before the update
Comment 5 Joe Breuer 2013-09-06 12:01:30 UTC
Created attachment 358046 [details]
Screenshot showing emerge's colors
Comment 6 Martin Väth 2013-09-06 14:48:41 UTC
This has all been discussed ad nauseam in bug 438076.
There is no solution which makes everybody happy.

> IMO, the background color of non-marked-up output should never be changed

Then there would be situations where output is non-readable which is
unacceptable, see bug 438076

Using poor 8 colors as default will not be happening again, since too many different informations would then be mapped to the same color.

> a) Setting 'SOLARIZED'

Unless you installed the solarized color scheme (you would know if you have done this, since it is not in the gentoo tree) do not touch this variable.

Your possibilities are the following:

1. Change to 8-color dark scheme everywhere by setting TERM_ALT3=.
This is probably what you want, but it hides a lot of information which
is otherwise visible in the colors and thus is not the default.

2. Write a complete 256-color scheme with well-readable (on black on white),
pleasing and distinguishable colors for all various information which in
addition is similar to portage's colors. If the scheme is nice, it can
replace the current corresponding color scheme #3 (256 colors light) in
future versions of eix (currently, readable and distinguishable colors are
considered more important than similarity with portage; the color scheme is
certainly far from ideal.)
Be aware, however, that you have to transport some 50 different informations
by colors, some needing to play well with marking by bold and inversion,
and everything with different shades of "white" background,
so writing such a scheme will be an issue of many hours.
I will not do it, since I get headache when working on white background for
a longer period.

*** This bug has been marked as a duplicate of bug 438076 ***
Comment 7 Martin Väth 2013-09-06 15:29:48 UTC
(In reply to Joachim Breuer from comment #0)
> AFAIK the "intense" option is turned on for the background

BTW, eix just sets the background to "white".
The default background on konsole just is not white but some shade of white depending on the colorscheme you selected in kde.
Comment 8 Joe Breuer 2013-09-06 16:53:27 UTC
(In reply to Martin Väth from comment #7)
> BTW, eix just sets the background to "white".
> The default background on konsole just is not white but some shade of white
> depending on the colorscheme you selected in kde.

Konsole calls it "white" for sure. I'd guess it's the color index in the second field of $COLORFGBG.

No matter, *no* other software seems to have this problem. Including portage/emerge.


http://dev.yorhel.nl/dump/nccolour has a nice chart; the following colors seem safe to me on dark and light backgrounds:

for readable text:
  non-"bold"   red, green, magenta, (yellow)
  "bold"       red, green, blue, magenta

additionally for marks (e.g. asterisks, arrows, ...):
  non-bold     blue, yellow, cyan
  "bold"       cyan


For short spans within lines, it is of course OK to set a specific background color (with a suitable foreground color). I mainly don't understand the perceived need to set the background color for body text output.


I'll put together a "safe" color scheme and put it in this ticket; whoever likes it can take it from there then.
Comment 9 Joe Breuer 2013-09-06 16:54:16 UTC
grr, bugzilla...

*** This bug has been marked as a duplicate of bug 438076 ***
Comment 10 Martin Väth 2013-09-07 07:33:57 UTC
(In reply to Joachim Breuer from comment #8)
> No matter, *no* other software seems to have this problem.

There is hardly any software which attempts to transport as much
information throught colors/markings. portage certainly does not.
Compare the output of e.g.

eix -vle gcc
eix -ce gcc -oe glibc -oe eix \
  -oe [a package from /etc/portage/sets/] \
  -oe [a package with a tarball] \
  -oe [a package from an overlay] \
eix -I [a package from a virtual overlay]
echo app-portage/eix-0.29.{1,3} | eix --pipe
eix-diff (e.g. when your kernel sources have changed)

where practically everything should look optically different,
some things should point out, and simultaneously a maximum of consistency
should be achieved.

> Konsole calls it "white" for sure. I'd guess it's the color index in the
> second field of $COLORFGBG.

No. $COLORFGBG outputs only certain fixed values; essentially just the
information whether the background is light or dark (and you are lucky
if terminals do even this correctly.)

eix --256 (or the related options 256b 256d 256l 256d0 256d1 256l0 256l1)
will show you the available colors.
Be aware that the tones might look different (and different ones are
optically non-distinguishalbe) on xterm, rxvt, aterm,
konsole, gnome-shell and possibly also depending on the color scheme.

For the 256 color schemes the "8/16 system colors" must not be used, since
they might look completely different, dependenig on Xresources (e.g. if the
solorized color scheme is installed, several of these colors are only
different shades of grey and thus might be non-distinguishable from
certain other colors, system colors 0/8/15 are inverted on some terminals).

> http://dev.yorhel.nl/dump/nccolour has a nice chart

This is for the 8/16 system colors changed by Xresources - eix cannot change/find out how these look like which is why they are taboo for
the 256 colors scheme.

> I'll put together a "safe" color scheme and put it in this ticket; whoever
> likes it can take it from there then.

By a color scheme I mean settting the (in your case 4th) entries in the
variables which you see with

eix --dump | grep '^\([^=]*COLOR\|MARK\)'

Be aware that the "MARK" variables are combined with "COLOR" in some cases.
They are contained in the eix sources in src/eixrc/defaults.cc

As mentioned above, if you produce a nice colorscheme, it might go
into src/eixrc/defaults.cc (as the 4th row or maybe as an alternative color
scheme which the user might select).
Necessary conditions for this are:
1. Must not use system colors (for reasons explained above)
2. All different markings items must look _optically_ different
and be readable, both being the case
3. for all choices of terminals xterm, rxvt, rxvt-unicode, aterm, konsole,
gnome with various choices of background shades of white and various
selection of color schemes in kde or gnome.
Note that the terminals display the colors somewhat differently.
Comment 11 Joe Breuer 2013-09-14 08:46:46 UTC
First of all, thanks *a lot* for the extensive explanation.

I understand the reasoning behind the current / "new default" eix color scheme now.

For what concerns me (different terminals, remote access, ...), the "old" 8/16 default color scheme is more useful than the new auto-selected 256 color default; and it was not obvious to me how to get the old colors back.

For the record, this can be *almost* achieved with:

  TERM_ALT3=.
  COLORSCHEME3=0

[Without COLORSCHEME3=0, the new 'light background' scheme would be auto-selected; which looks completely different than the old scheme - not only in brightness.]

This addresses my immediate needs.

In that regard, I find that the old default 8/16 color scheme of eix (as well as the color schemes used by portage, eselect etc.) did an excellent job. People not *used* to the old eix output may very well find the new default schemes even more useful.


Getting back to the *almost*: 

* Installed packages are marked inverse in the old/'0' colorscheme. I'm very fond of this very obvious marking.

* Inverse output is also used on the "Installed versions:" line, for consistency. I'm very fond of this consistency too.

* The new '0' colorscheme puts the installed version numbers black on (dark) blue, that's too dark to be readable on mostly bright (i.e. white background) terminals.

* The old colorscheme used inverse with (the same dark) blue, with bold also turned on. (This comes out as BG on blue, so white on blue here). I find it also readable as black on blue when using a black BG.

- The old additional 'bold' for that field is not that appropriate (IMO), since the inverted mark of installed packages in the "Available versions:" line is not bold either.

The exact old styling can be achieved with this additional configuration:
  COLOR_INST_VERSION="bold;inverse;blue;"

and I can easily leave off the 'bold;' to have what looks most natural to me:
  COLOR_INST_VERSION="inverse;blue;"

[when not using scheme 0, put this in the appropriate place of the pipe separated list].

For other folks having similar issues, 'eix --dump' shows the complete configuration including docs as a starting point; also see Martin's notes about the colorschemes.


(In reply to Martin Väth from comment #10)
> (In reply to Joachim Breuer from comment #8)
> > No matter, *no* other software seems to have this problem.
> 
> There is hardly any software which attempts to transport as much
> information throught colors/markings. portage certainly does not.
> Compare the output of e.g.
> 
> eix -vle gcc
> eix -ce gcc -oe glibc -oe eix \
>   -oe [a package from /etc/portage/sets/] \
>   -oe [a package with a tarball] \
>   -oe [a package from an overlay] \
> eix -I [a package from a virtual overlay]
> echo app-portage/eix-0.29.{1,3} | eix --pipe
> eix-diff (e.g. when your kernel sources have changed)
> 
> where practically everything should look optically different,
> some things should point out, and simultaneously a maximum of consistency
> should be achieved.

For all these, the legacy color scheme is more usable *for me* (probably because I'm used to it).

I've looked them over and I cannot find color contrasts that are present in the 256 color scheme that are not also shown with the legacy scheme. Sure, the same color means more things with the old scheme, but *I* actually find that the contrasts drawing my attention to points in the output is reduced with the new scheme.

That last is probably just me used to the old hammer-in-the-eye scheme ;-)

I noticed that the new scheme overuses bold for my taste - in the above examples more than 50% of the output appears bold. I (again, possibly personal preference) find bold to be a very strong marker, similar to inverse or red color, that should be used more sparingly.

> > Konsole calls it "white" for sure. I'd guess it's the color index in the
> > second field of $COLORFGBG.
> 
> No. $COLORFGBG outputs only certain fixed values; essentially just the
> information whether the background is light or dark (and you are lucky
> if terminals do even this correctly.)

I beg to differ. AFAIK $COLORFGBG was introduced by rxvt; and it puts the terminal colors (i.e. from an 'escape code standpoint') used for FG and BG there.

See rxvt_set_colorfgbg() in http://sourceforge.net/p/rxvt/code/HEAD/tree/trunk/src/main.c (lines 937ff.)

> eix --256 (or the related options 256b 256d 256l 256d0 256d1 256l0 256l1)
> will show you the available colors.
> Be aware that the tones might look different (and different ones are
> optically non-distinguishalbe) on xterm, rxvt, aterm,
> konsole, gnome-shell and possibly also depending on the color scheme.

Ah, that's nice!

It also shows that the 256 color schemes insist on setting the background even if only the foreground is shown; and that background 'white' is not properly white for me. I'm not saying this is a bug in eix, might be anywhere - end result is that the output looks weird.

If it were for me to decide I'd use 'transparent' (i.e. not set) as the default for the background color (and choose the FG scheme according to whatever light/dark detection found), and deal with "I want the BG to be opaque" in an FAQ.

All other software that generates textual output and that I can think of right now defaults to transparent for the BG and possibly allows the user to explicitly override that.

But preferring that way may just be my opinion again.

> For the 256 color schemes the "8/16 system colors" must not be used, since
> they might look completely different, dependenig on Xresources (e.g. if the
> solorized color scheme is installed, several of these colors are only
> different shades of grey and thus might be non-distinguishable from
> certain other colors, system colors 0/8/15 are inverted on some terminals).
> 
> > http://dev.yorhel.nl/dump/nccolour has a nice chart
> 
> This is for the 8/16 system colors changed by Xresources - eix cannot
> change/find out how these look like which is why they are taboo for
> the 256 colors scheme.

OK, I got that now - especially that 256 is considered the new default; which is perfectly acceptable.

The "emotional attachment" I have to the old output (== the energy I have writing this up) goes a long way to show how important such things can become, and how integral eix has become for me.

> > I'll put together a "safe" color scheme and put it in this ticket; whoever
> > likes it can take it from there then.
> 
> By a color scheme I mean settting the (in your case 4th) entries in the
> variables which you see with
> 
> eix --dump | grep '^\([^=]*COLOR\|MARK\)'
> 
> Be aware that the "MARK" variables are combined with "COLOR" in some cases.
> They are contained in the eix sources in src/eixrc/defaults.cc
> 
> As mentioned above, if you produce a nice colorscheme, it might go
> into src/eixrc/defaults.cc (as the 4th row or maybe as an alternative color
> scheme which the user might select).
> Necessary conditions for this are:
> 1. Must not use system colors (for reasons explained above)
> 2. All different markings items must look _optically_ different
> and be readable, both being the case
> 3. for all choices of terminals xterm, rxvt, rxvt-unicode, aterm, konsole,
> gnome with various choices of background shades of white and various
> selection of color schemes in kde or gnome.
> Note that the terminals display the colors somewhat differently.

I probably won't invest the effort to design a proper full 256 color map (and need to get used to that map myself).

That's not to say it can't/shouldn't be done, but for productive command-line tools (i.e. simply producing textual output, not having an interactive UI like e.g. mc) *I* find that more than 8/16 colors does not convey more processable information (for me). Rather use punctuation, placement etc.

Until today, I was under the impression that the exact color scheme used before the upgrade was not available at all in the new version, and in that case I'd have put together an 8/16 color scheme based on the old default.

OK, I'll shut up now ;-)
Comment 12 Martin Väth 2013-09-14 13:15:25 UTC
(In reply to Joachim Breuer from comment #11)

> * Inverse output is also used on the "Installed versions:" line, for
> consistency. I'm very fond of this consistency too.

Inverse colors had caused a lot of problems for different users:
The choice from early eix version turned out to be unreadable e.g. with solarized, variants of it are badly readable either on dark or light background, and others variants (with forcing color light or black) turned out bad on other terminals, again.

After changing the default three times and then still getting complaints by some users, I decided to keep with non-inverse colors wherever possible, marking of installed versions in the list of available versions remaining the only exception.

Of course, I encourage you to change the color to your taste,
but for the default readability should be more important.

> I beg to differ. AFAIK $COLORFGBG was introduced by rxvt

Maybe rxvt was the first and handles it that way.
However, look e.g. at the konsole sources:
_hasDarkBackground ? "COLORFGBG=15;0" : "COLORFGBG=0;15"
rxvt-unicode with XPM support gives yet another interpretation, and who knows what other terminals do...

Anyway, eix does not more with COLORFGBG than to decide whether the background is light or dark.

> It also shows that the 256 color schemes insist on setting the background

No, the algorithm implementing --256 just sets the background explicitly
(see src/eixTk/ansicolor_print.cc):
Otherwise, some numbers would be invisible...

> If it were for me to decide I'd use 'transparent' (i.e. not set) as the
> default for the background color

This was the original setting, but since the background color detection
does not work reliable, this can produce invisible/unreadable texts.
Readability is more important for the default setting than anything else -
better ugly colors than non-readable ones.