tty[1-6]: colors a negative accessibility/usability trend

tty[1-6]: colors a negative accessibility/usability trend

[Felix Miata]

Red, blue and green in particular produce poor contrast on the black
background of a typical framebuffer screen. As these screens are configured
as functional twins of those modes we find outselves in at rescue time, it
amounts to an unfortunate and unnecessary accessibility/usability obstacle
that is IMO is a subset of a larger general problem found under the moniker
A11Y[1].

A very good, very recent article discusses the mindset that leads to default
settings that thwart use by the disadvantaged[2], however slight that
impediment may be.

With util-linux >= 2.25 we can turn colors off via

	# touch /etc/terminal-colors.d/disable [3]

for some commands, but far too few. It should apply to all, including many
outside the purview of util-linux, and more importantly, do so by default.

It should be up to those who wish a legibility reduction to discover how to
and apply the reduction, not the other way around as it is now. It is much
more difficult for those who cannot handle low contrast to improve it than
for those who find it too high to reduce it, a variation on the chicken/egg
paradigm.

If we can get all components of util-linux to adhere to maximizing
legibility, it would have the potential serve as an important springboard for
other projects to do the same, and maybe even spill onto the web.

[1] http://a11yproject.com/
[2] http://alistapart.com/article/reframing-accessibility-for-the-web
[3] http://karelzak.blogspot.de/2014/04/terminal-colorsd.html
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: tty[1-6]: colors a negative accessibility/usability trend

[Pádraig Brady]

On 12/02/15 09:45, Felix Miata wrote:
> Red, blue and green in particular produce poor contrast on the black
> background of a typical framebuffer screen.

Agreed, though the bold variants are better.
Better again are 256 color variants.
The Linux console lagged xterms in support, but does support it now.

> As these screens are configured
> as functional twins of those modes we find ourselves in at rescue time, it
> amounts to an unfortunate and unnecessary accessibility/usability obstacle
> that is IMO is a subset of a larger general problem found under the moniker
> A11Y[1].
> 
> A very good, very recent article discusses the mindset that leads to default
> settings that thwart use by the disadvantaged[2], however slight that
> impediment may be.

I agree completely. color is useful but one has to be very careful
in how it's used. ls --color for example is too aggressive IMHO,
and I adjust to highlight rather than color with:
  http://www.pixelbeat.org/scripts/l
I've been pusing back upstream against adding new color combinations.

> With util-linux >= 2.25 we can turn colors off via
> 
> 	# touch /etc/terminal-colors.d/disable [3]
> 
> for some commands, but far too few. It should apply to all, including many
> outside the purview of util-linux, and more importantly, do so by default.

coreutils will keep this scheme in mind too.

thanks,
Pádraig.

Re: tty[1-6]: colors a negative accessibility/usability trend

[Dale R. Worley]

<P@draigBrady.com> writes:
> I agree completely. color is useful but one has to be very careful
> in how it's used. ls --color for example is too aggressive IMHO,
> and I adjust to highlight rather than color with:
>   http://www.pixelbeat.org/scripts/l
> I've been pusing back upstream against adding new color combinations.

I don't particularly like colorization.  But technically, it seems to me
that what is needed is a systematic way for the user to indicate his
colorization preferences to *all* utilities.  And a corresponding way
for the system to provide defaults for those user preferences.

Only when there is a systematic framework for colorization will all the
programs allow colorizing to be configured.

Dale

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Thu, Feb 12, 2015 at 10:21:48PM -0500, Dale R. Worley wrote:
> I don't particularly like colorization.  But technically, it seems to me
> that what is needed is a systematic way for the user to indicate his
> colorization preferences to *all* utilities.  And a corresponding way
> for the system to provide defaults for those user preferences.
>
> 
> Only when there is a systematic framework for colorization will all the
> programs allow colorizing to be configured.

It would be possible to create a shared library from our lib/colors.c
to support terminal-colors.d/... :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Sami Kerola]

On 13 February 2015 at 09:21, Karel Zak <kzak@redhat.com> wrote:
> On Thu, Feb 12, 2015 at 10:21:48PM -0500, Dale R. Worley wrote:
>> I don't particularly like colorization.  But technically, it seems to me
>> that what is needed is a systematic way for the user to indicate his
>> colorization preferences to *all* utilities.  And a corresponding way
>> for the system to provide defaults for those user preferences.
>>
>>
>> Only when there is a systematic framework for colorization will all the
>> programs allow colorizing to be configured.
>
> It would be possible to create a shared library from our lib/colors.c
> to support terminal-colors.d/... :-)

Or add the needed to ncurses. Isn't that better than adding a new
library?

-- 
Sami Kerola
http://www.iki.fi/kerolasa/

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Fri, Feb 13, 2015 at 10:33:23AM +0000, Sami Kerola wrote:
> On 13 February 2015 at 09:21, Karel Zak <kzak@redhat.com> wrote:
> > On Thu, Feb 12, 2015 at 10:21:48PM -0500, Dale R. Worley wrote:
> >> I don't particularly like colorization.  But technically, it seems to me
> >> that what is needed is a systematic way for the user to indicate his
> >> colorization preferences to *all* utilities.  And a corresponding way
> >> for the system to provide defaults for those user preferences.
> >>
> >>
> >> Only when there is a systematic framework for colorization will all the
> >> programs allow colorizing to be configured.
> >
> > It would be possible to create a shared library from our lib/colors.c
> > to support terminal-colors.d/... :-)
> 
> Or add the needed to ncurses. Isn't that better than adding a new
> library?

you want to link programs like dmesg, gcc or ls with ncurses monster?

The another story is that ncurses provides completely abstract layer
for colors and I didn't found a way how to use it together with color 
escape sequences. This is reason why for example cfdisk supports only
enable/disable terminal-colors.d feature, but no schemes to specify
colors.
    
    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On 13 Feb 2015 12:25, Karel Zak wrote:
> On Fri, Feb 13, 2015 at 10:33:23AM +0000, Sami Kerola wrote:
> > On 13 February 2015 at 09:21, Karel Zak <kzak@redhat.com> wrote:
> > > On Thu, Feb 12, 2015 at 10:21:48PM -0500, Dale R. Worley wrote:
> > >> I don't particularly like colorization.  But technically, it seems to me
> > >> that what is needed is a systematic way for the user to indicate his
> > >> colorization preferences to *all* utilities.  And a corresponding way
> > >> for the system to provide defaults for those user preferences.
> > >>
> > >>
> > >> Only when there is a systematic framework for colorization will all the
> > >> programs allow colorizing to be configured.
> > >
> > > It would be possible to create a shared library from our lib/colors.c
> > > to support terminal-colors.d/... :-)
> > 
> > Or add the needed to ncurses. Isn't that better than adding a new
> > library?
> 
> you want to link programs like dmesg, gcc or ls with ncurses monster?
> 
> The another story is that ncurses provides completely abstract layer
> for colors and I didn't found a way how to use it together with color 
> escape sequences. This is reason why for example cfdisk supports only
> enable/disable terminal-colors.d feature, but no schemes to specify
> colors.

this is why ncurses has the ability to split its lib into a smaller libtinfo.  
you get all the logic for detecting terminal capabilities without all the rest 
of the ncurses layers.  for people who do want to kill colors across the board, 
they can use a different TERM that does not support them.  forcing people to 
duplicate that in a new database seems wrong to me.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Sun, Feb 15, 2015 at 06:12:38AM -0500, Mike Frysinger wrote:
> On 13 Feb 2015 12:25, Karel Zak wrote:
> > On Fri, Feb 13, 2015 at 10:33:23AM +0000, Sami Kerola wrote:
> > > On 13 February 2015 at 09:21, Karel Zak <kzak@redhat.com> wrote:
> > > > On Thu, Feb 12, 2015 at 10:21:48PM -0500, Dale R. Worley wrote:
> > > >> I don't particularly like colorization.  But technically, it seems to me
> > > >> that what is needed is a systematic way for the user to indicate his
> > > >> colorization preferences to *all* utilities.  And a corresponding way
> > > >> for the system to provide defaults for those user preferences.
> > > >>
> > > >>
> > > >> Only when there is a systematic framework for colorization will all the
> > > >> programs allow colorizing to be configured.
> > > >
> > > > It would be possible to create a shared library from our lib/colors.c
> > > > to support terminal-colors.d/... :-)
> > > 
> > > Or add the needed to ncurses. Isn't that better than adding a new
> > > library?
> > 
> > you want to link programs like dmesg, gcc or ls with ncurses monster?
> > 
> > The another story is that ncurses provides completely abstract layer
> > for colors and I didn't found a way how to use it together with color 
> > escape sequences. This is reason why for example cfdisk supports only
> > enable/disable terminal-colors.d feature, but no schemes to specify
> > colors.
> 
> this is why ncurses has the ability to split its lib into a smaller libtinfo.  
> you get all the logic for detecting terminal capabilities without all the rest 
> of the ncurses layers.  for people who do want to kill colors across the board, 
> they can use a different TERM that does not support them.  forcing people to 
> duplicate that in a new database seems wrong to me.

 What we want to duplicate? What exactly in lib/colors.c is duplicate?
 The code evaluates filenames and parses files with "name colorcode".

 Anyway, the core of the terminal-colors.d/ is enable/disable feature,
 for this purpose is unnecessary any library.

    Karel

> -mike



-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2361 bytes --]

On 16 Feb 2015 10:10, Karel Zak wrote:
> On Sun, Feb 15, 2015 at 06:12:38AM -0500, Mike Frysinger wrote:
> > On 13 Feb 2015 12:25, Karel Zak wrote:
> > > On Fri, Feb 13, 2015 at 10:33:23AM +0000, Sami Kerola wrote:
> > > > On 13 February 2015 at 09:21, Karel Zak <kzak@redhat.com> wrote:
> > > > > On Thu, Feb 12, 2015 at 10:21:48PM -0500, Dale R. Worley wrote:
> > > > >> I don't particularly like colorization.  But technically, it seems to me
> > > > >> that what is needed is a systematic way for the user to indicate his
> > > > >> colorization preferences to *all* utilities.  And a corresponding way
> > > > >> for the system to provide defaults for those user preferences.
> > > > >>
> > > > >>
> > > > >> Only when there is a systematic framework for colorization will all the
> > > > >> programs allow colorizing to be configured.
> > > > >
> > > > > It would be possible to create a shared library from our lib/colors.c
> > > > > to support terminal-colors.d/... :-)
> > > > 
> > > > Or add the needed to ncurses. Isn't that better than adding a new
> > > > library?
> > > 
> > > you want to link programs like dmesg, gcc or ls with ncurses monster?
> > > 
> > > The another story is that ncurses provides completely abstract layer
> > > for colors and I didn't found a way how to use it together with color 
> > > escape sequences. This is reason why for example cfdisk supports only
> > > enable/disable terminal-colors.d feature, but no schemes to specify
> > > colors.
> > 
> > this is why ncurses has the ability to split its lib into a smaller libtinfo.  
> > you get all the logic for detecting terminal capabilities without all the rest 
> > of the ncurses layers.  for people who do want to kill colors across the board, 
> > they can use a different TERM that does not support them.  forcing people to 
> > duplicate that in a new database seems wrong to me.
> 
>  What we want to duplicate? What exactly in lib/colors.c is duplicate?
>  The code evaluates filenames and parses files with "name colorcode".

whether the terminal even supports color in the first place.  if i picked a 
terminal that doesn't support color so i didn't have to worry about it, it's a 
bit crazy i also have to go to multiple config files and also tell them i don't 
want color otherwise i get corrupted output.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Mon, Feb 16, 2015 at 04:35:33AM -0500, Mike Frysinger wrote:
> On 16 Feb 2015 10:10, Karel Zak wrote:
> >  What we want to duplicate? What exactly in lib/colors.c is duplicate?
> >  The code evaluates filenames and parses files with "name colorcode".
> 
> whether the terminal even supports color in the first place.  if i picked a 
> terminal that doesn't support color so i didn't have to worry about it, it's a 
> bit crazy i also have to go to multiple config files and also tell them i don't 
> want color otherwise i get corrupted output.

For now it checks isatty() and nothing else, it would be possible to
check number of supported colors in terminfo too, or is there any
other way?

Anyway, we don't want to create (duplicate) any database, all it
provides are knobs for customization and enable/disable.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Samuel Thibault]

Karel Zak, le Mon 16 Feb 2015 10:47:47 +0100, a écrit :
> On Mon, Feb 16, 2015 at 04:35:33AM -0500, Mike Frysinger wrote:
> > On 16 Feb 2015 10:10, Karel Zak wrote:
> > >  What we want to duplicate? What exactly in lib/colors.c is duplicate?
> > >  The code evaluates filenames and parses files with "name colorcode".
> > 
> > whether the terminal even supports color in the first place.  if i picked a 
> > terminal that doesn't support color so i didn't have to worry about it, it's a 
> > bit crazy i also have to go to multiple config files and also tell them i don't 
> > want color otherwise i get corrupted output.
> 
> For now it checks isatty() and nothing else, it would be possible to
> check number of supported colors in terminfo too, or is there any
> other way?

It should also check how to change the colors. Not all terminals will
support the ANSI way.

> Anyway, we don't want to create (duplicate) any database, all it
> provides are knobs for customization and enable/disable.

It provides only that because the source code currently hardcodes the
\033[%sm sequence, but it really should not, and use terminfo instead.

Samuel

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Mon, Feb 16, 2015 at 11:32:41AM +0100, Samuel Thibault wrote:
> It should also check how to change the colors. Not all terminals will
> support the ANSI way.
> 
> > Anyway, we don't want to create (duplicate) any database, all it
> > provides are knobs for customization and enable/disable.
> 
> It provides only that because the source code currently hardcodes the
> \033[%sm sequence, but it really should not, and use terminfo instead.

 Good point, I'm ready to accept patches to implement this feature :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Mon, Feb 16, 2015 at 11:32:41AM +0100, Samuel Thibault wrote:
> Karel Zak, le Mon 16 Feb 2015 10:47:47 +0100, a écrit :
> > On Mon, Feb 16, 2015 at 04:35:33AM -0500, Mike Frysinger wrote:
> > > On 16 Feb 2015 10:10, Karel Zak wrote:
> > > >  What we want to duplicate? What exactly in lib/colors.c is duplicate?
> > > >  The code evaluates filenames and parses files with "name colorcode".
> > > 
> > > whether the terminal even supports color in the first place.  if i picked a 
> > > terminal that doesn't support color so i didn't have to worry about it, it's a 
> > > bit crazy i also have to go to multiple config files and also tell them i don't 
> > > want color otherwise i get corrupted output.
> > 
> > For now it checks isatty() and nothing else, it would be possible to
> > check number of supported colors in terminfo too, or is there any
> > other way?
> 
> It should also check how to change the colors. Not all terminals will
> support the ANSI way.

 OK, linked with libtinfo, now it checks if the current terminal supports 
 colors ("colors" from tinfo) and all the stuff is disabled for terminals
 like vt100.

> > Anyway, we don't want to create (duplicate) any database, all it
> > provides are knobs for customization and enable/disable.
> 
> It provides only that because the source code currently hardcodes the
> \033[%sm sequence, but it really should not, and use terminfo instead.

 This is not implemented yet, I (or any volunteer?) will try to add to code 
 an extra layer to avoid the hardcoded sequences and read the colors from terminfo.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Pádraig Brady]

On 27/02/15 13:48, Karel Zak wrote:
> On Mon, Feb 16, 2015 at 11:32:41AM +0100, Samuel Thibault wrote:
>> Karel Zak, le Mon 16 Feb 2015 10:47:47 +0100, a écrit :
>>> On Mon, Feb 16, 2015 at 04:35:33AM -0500, Mike Frysinger wrote:
>>>> On 16 Feb 2015 10:10, Karel Zak wrote:
>>>>>  What we want to duplicate? What exactly in lib/colors.c is duplicate?
>>>>>  The code evaluates filenames and parses files with "name colorcode".
>>>>
>>>> whether the terminal even supports color in the first place.  if i picked a 
>>>> terminal that doesn't support color so i didn't have to worry about it, it's a 
>>>> bit crazy i also have to go to multiple config files and also tell them i don't 
>>>> want color otherwise i get corrupted output.
>>>
>>> For now it checks isatty() and nothing else, it would be possible to
>>> check number of supported colors in terminfo too, or is there any
>>> other way?
>>
>> It should also check how to change the colors. Not all terminals will
>> support the ANSI way.
> 
>  OK, linked with libtinfo, now it checks if the current terminal supports 
>  colors ("colors" from tinfo) and all the stuff is disabled for terminals
>  like vt100.
> 
>>> Anyway, we don't want to create (duplicate) any database, all it
>>> provides are knobs for customization and enable/disable.
>>
>> It provides only that because the source code currently hardcodes the
>> \033[%sm sequence, but it really should not, and use terminfo instead.
> 
>  This is not implemented yet, I (or any volunteer?) will try to add to code 
>  an extra layer to avoid the hardcoded sequences and read the colors from terminfo.

I'd be careful to not over engineer that.
coreutils currently hardcodes ansi sequences,
and I've not heard specific complaints about it.
What terminals are not catered for here?

Re: tty[1-6]: colors a negative accessibility/usability trend

[Peter Cordes]

On Sun, Mar 01, 2015 at 01:32:01PM +0000, Pádraig Brady wrote:
> On 27/02/15 13:48, Karel Zak wrote:
> >  This is not implemented yet, I (or any volunteer?) will try to add to code 
> >  an extra layer to avoid the hardcoded sequences and read the colors from terminfo.
> 
> I'd be careful to not over engineer that.
> coreutils currently hardcodes ansi sequences,
> and I've not heard specific complaints about it.
> What terminals are not catered for here?

 At this point, it's hard to imagine anyone writing a new terminal
emulator with incompatible color escape sequences.

 Anyone on really rare hardware terminals or crufty software that is
different for some reason can always disable colors for software that
hard-codes sequences.  They're nice but non-essential.

 The only scenario I'm coming up with where it would be really good to
use a library to find what escape sequences to use would be
future-proofing against the day when somebody extends the ANSI color
escape sequences to support more colors, or 3D for stereoscopic-vision
terminals.  And even then, only if for some reason they choose to
extend the escape sequences in a non-backwards-compat way.

 I'd hold off on spending time on this until some new idea
for color escape codes comes along.  I think there's enough inertia
behind the current ANSI escape sequences that terminal emulators will
need to support current-style escape sequences for decades after the
appearance of a new way of doing things.  I think decades is long
enough for util-linux to make this proposed change and have it
percolate into long-term-support releases before any terminal
emulators think they can get away with dropping support for
current-style color escape sequences.

 Anyway, that's my 2 cents.  I'd maybe change my mind if anyone has a
real-life case where the hardcoded ANSI codes don't work for them, on
a terminal they actually want to use, but terminfo would.  (I'm not
talking about ancient cruft you can find that's incompat, but rather
stuff people actually do use regularly.)

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Sun, Mar 01, 2015 at 01:32:01PM +0000, Pádraig Brady wrote:
> On 27/02/15 13:48, Karel Zak wrote:
> > On Mon, Feb 16, 2015 at 11:32:41AM +0100, Samuel Thibault wrote:
> >> Karel Zak, le Mon 16 Feb 2015 10:47:47 +0100, a écrit :
> >>> On Mon, Feb 16, 2015 at 04:35:33AM -0500, Mike Frysinger wrote:
> >>>> On 16 Feb 2015 10:10, Karel Zak wrote:
> >>>>>  What we want to duplicate? What exactly in lib/colors.c is duplicate?
> >>>>>  The code evaluates filenames and parses files with "name colorcode".
> >>>>
> >>>> whether the terminal even supports color in the first place.  if i picked a 
> >>>> terminal that doesn't support color so i didn't have to worry about it, it's a 
> >>>> bit crazy i also have to go to multiple config files and also tell them i don't 
> >>>> want color otherwise i get corrupted output.
> >>>
> >>> For now it checks isatty() and nothing else, it would be possible to
> >>> check number of supported colors in terminfo too, or is there any
> >>> other way?
> >>
> >> It should also check how to change the colors. Not all terminals will
> >> support the ANSI way.
> > 
> >  OK, linked with libtinfo, now it checks if the current terminal supports 
> >  colors ("colors" from tinfo) and all the stuff is disabled for terminals
> >  like vt100.
> > 
> >>> Anyway, we don't want to create (duplicate) any database, all it
> >>> provides are knobs for customization and enable/disable.
> >>
> >> It provides only that because the source code currently hardcodes the
> >> \033[%sm sequence, but it really should not, and use terminfo instead.
> > 
> >  This is not implemented yet, I (or any volunteer?) will try to add to code 
> >  an extra layer to avoid the hardcoded sequences and read the colors from terminfo.
> 
> I'd be careful to not over engineer that.
> coreutils currently hardcodes ansi sequences,

Yes, I know about it and coreutils has been my specimen for terminal-colors :-)

> and I've not heard specific complaints about it.
> What terminals are not catered for here?

I don't know, my plan is to do some research to better understand what
Samuel is talking about.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Samuel Thibault]

Karel Zak, le Mon 02 Mar 2015 09:59:29 +0100, a écrit :
> On Sun, Mar 01, 2015 at 01:32:01PM +0000, Pádraig Brady wrote:
> > and I've not heard specific complaints about it.
> > What terminals are not catered for here?
> 
> I don't know, my plan is to do some research to better understand what
> Samuel is talking about.

Mmm, I thought it was well-known, but apparently not :/

I mean using this (see terminfo(5) for the details):

#include <term.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
  int my_bg_color = 0;
  int my_fg_color = 4;

  setupterm(NULL, STDOUT_FILENO, NULL);
  tputs(enter_bold_mode, 1, putchar);
  tputs(enter_italics_mode, 1, putchar);
  tputs(enter_underline_mode, 1, putchar);
  tputs(enter_blink_mode, 1, putchar);
  tputs(enter_reverse_mode, 1, putchar);
  tputs(tparm(set_a_foreground, my_fg_color), 1, putchar);
  tputs(tparm(set_a_background, my_bg_color), 1, putchar);
  printf("Hello, world!\n");
  tputs(exit_attribute_mode, 1, putchar);
  return 0;
}

On terminals which support it, you can even get rgb colors by using
initialize_color or initialize_pair. If you want a more complete
example, see lstopo-text.c inside the hwloc package, we include ncurses,
but we don't actually need it for this kind of code. Try with

lstopo -.txt

Doing it really properly as exampled above doesn't look terribly
overengineered to me.

Samuel

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Mon, Mar 02, 2015 at 10:31:46AM +0100, Samuel Thibault wrote:
> Karel Zak, le Mon 02 Mar 2015 09:59:29 +0100, a écrit :
> > On Sun, Mar 01, 2015 at 01:32:01PM +0000, Pádraig Brady wrote:
> > > and I've not heard specific complaints about it.
> > > What terminals are not catered for here?
> > 
> > I don't know, my plan is to do some research to better understand what
> > Samuel is talking about.
> 
> Mmm, I thought it was well-known, but apparently not :/
> 
> I mean using this (see terminfo(5) for the details):
> 
> #include <term.h>
> #include <stdio.h>
> #include <unistd.h>
> 
> int main(void) {
>   int my_bg_color = 0;
>   int my_fg_color = 4;
> 
>   setupterm(NULL, STDOUT_FILENO, NULL);
>   tputs(enter_bold_mode, 1, putchar);
>   tputs(enter_italics_mode, 1, putchar);
>   tputs(enter_underline_mode, 1, putchar);
>   tputs(enter_blink_mode, 1, putchar);
>   tputs(enter_reverse_mode, 1, putchar);
>   tputs(tparm(set_a_foreground, my_fg_color), 1, putchar);
>   tputs(tparm(set_a_background, my_bg_color), 1, putchar);
>   printf("Hello, world!\n");
>   tputs(exit_attribute_mode, 1, putchar);
>   return 0;
> }
> 
> On terminals which support it, you can even get rgb colors by using
> initialize_color or initialize_pair. If you want a more complete
> example, see lstopo-text.c inside the hwloc package, we include ncurses,
> but we don't actually need it for this kind of code. 

This is misunderstanding, I know about tputs :)

The question is how often the harcoded sequences are problem, which
terminals? how often people use it? Would be enough to detect these
terminals and use things without colors there?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Dale R. Worley]

Sami Kerola <kerolasa@iki.fi> writes:
> Or add the needed to ncurses. Isn't that better than adding a new
> library?

That would work, but only for utilities that use ncurses.  OTOH, it
would be good if ncurses understood and provided information from the
general color configuration to programs that use it.

Bruce Dubbs <bruce.dubbs@gmail.com> writes:
> Why not use the LS_COLORS environment variable used by coreutils' dircolors? 
> Does util-linux need to create something different?

Using an environment variable is the standard Unix way of configuring
the user-oriented behavior of programs.  But the "definition" of
LS_COLORS seems to be very specific to "ls".

The /etc/terminal-colors.d system seems a bit oversized (all those
files!), but it seems unlikely that anything simpler would work for a
large set of utilities, each of which the user may want to customize.

The main deficiency of terminal-colors.d is that it's system-wide.  But
I see this in a blog:

    $HOME/.config/terminal-colors.d overrides the global setting

so that is taken care of.

You also want to define an environment variable to override *that*,
e.g., files in $UTIL_LINUX_TERMINAL_COLORS override the ones in
$HOME/.config/terminal-colors.d -- that allows you to set up custom
environments for particular trees of processes by creating a suitable
colors directory and setting UTIL_LINUX_TERMINAL_COLORS.

Dale

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Sun, Feb 15, 2015 at 12:38:32PM -0500, Dale R. Worley wrote:
> Bruce Dubbs <bruce.dubbs@gmail.com> writes:
> > Why not use the LS_COLORS environment variable used by coreutils' dircolors? 
> > Does util-linux need to create something different?

because it's absolutely inelegant solution

 echo $LS_COLORS | wc --bytes
 1710

> The main deficiency of terminal-colors.d is that it's system-wide.  But
> I see this in a blog:
> 
>     $HOME/.config/terminal-colors.d overrides the global setting

it's already implemented.

 http://man7.org/linux/man-pages/man5/terminal-colors.d.5.html

> You also want to define an environment variable to override *that*,
> e.g., files in $UTIL_LINUX_TERMINAL_COLORS override the ones in
> $HOME/.config/terminal-colors.d -- that allows you to set up custom
> environments for particular trees of processes by creating a suitable
> colors directory and setting UTIL_LINUX_TERMINAL_COLORS.

for now it follows 

       $XDG_CONFIG_HOME/terminal-colors.d
       $HOME/.config/terminal-colors.d
       /etc/terminal-colors.d


 Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Bruce Dubbs]

Karel Zak wrote:
> On Thu, Feb 12, 2015 at 10:21:48PM -0500, Dale R. Worley wrote:
>> I don't particularly like colorization.  But technically, it seems to me
>> that what is needed is a systematic way for the user to indicate his
>> colorization preferences to *all* utilities.  And a corresponding way
>> for the system to provide defaults for those user preferences.
>>
>>
>> Only when there is a systematic framework for colorization will all the
>> programs allow colorizing to be configured.
>
> It would be possible to create a shared library from our lib/colors.c
> to support terminal-colors.d/... :-)

Why not use the LS_COLORS environment variable used by coreutils' dircolors? 
Does util-linux need to create something different?

   -- Bruce

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Thu, Feb 12, 2015 at 04:45:18AM -0500, Felix Miata wrote:
> With util-linux >= 2.25 we can turn colors off via
> 
> 	# touch /etc/terminal-colors.d/disable [3]
> 
> for some commands, but far too few. It should apply to all, including many
> outside the purview of util-linux, and more importantly, do so by default.

This is never ending story and there is no setting which works for
everyone. All I want to provide tools to make it possible to support
various use-cases. It's downstream (distors) job to provide knobs to
switch between the use-cases (profiles).

For example I can imagine packages 
   fedora-terminal-colors-{high-contrast,disable,...}.rpm
to setup coreutils, util-linux, gcc, ... whatever.

> It should be up to those who wish a legibility reduction to discover how to
> and apply the reduction, not the other way around as it is now. It is much
> more difficult for those who cannot handle low contrast to improve it than
> for those who find it too high to reduce it, a variation on the chicken/egg
> paradigm.

We can also add --{disable,enable}-colors-by-default to move the
decision to downstream and use default according the current
terminal-colors.d setting. Your default will be disable, my enabled.

For example for fedora I will keep the colors enabled, because it's
current distribution policy.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Samuel Thibault]

Karel Zak, le Thu 12 Feb 2015 14:21:10 +0100, a écrit :
> For example for fedora I will keep the colors enabled, because it's
> current distribution policy.

But all distributions need to be accessible.  It is a per-user
preference, not a per-task or per-distribution preference.  So upstream
at least needs to provide ways to configure it per user, and downstream
provide a uniform way to configure the various shipped tools.

Samuel

Re: tty[1-6]: colors a negative accessibility/usability trend

[Karel Zak]

On Thu, Feb 12, 2015 at 02:56:49PM +0100, Samuel Thibault wrote:
> Karel Zak, le Thu 12 Feb 2015 14:21:10 +0100, a écrit :
> > For example for fedora I will keep the colors enabled, because it's
> > current distribution policy.
> 
> But all distributions need to be accessible.

I'll be happy to provide support for both ways (colors and
non-colors) as downstream maintainer, but for example Fedora 
does not care... (for now).

> It is a per-user
> preference, not a per-task or per-distribution preference.  So upstream
> at least needs to provide ways to configure it per user, and downstream
> provide a uniform way to configure the various shipped tools.

Yeah, util-linux upstream already provides per-user (or per-machine)
configuration for colors (man terminal-colors.d). It would be nice to
support this in another packages too. Then we can improve things on
downstream level.

We have tons of crazy themes for desktops UI, mp3 playes, web
browsers, etc. It's time to support something like this for terminals
too ;-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: tty[1-6]: colors a negative accessibility/usability trend

[Edward d'Auvergne]

U2FtdWVsIFRoaWJhdWx0IDxzYW11ZWwudGhpYmF1bHRALi4uPiB3cml0ZXM6Cgo+IAo+IEthcmVsIFphaywgbGUgVGh1IDEyIEZlYiAyMDE1IDE0OjIxOjEwICswMTAwLCBhIMOpY3JpdCA6Cj4gPiBGb3IgZXhhbXBsZSBmb3IgZmVkb3JhIEkgd2lsbCBrZWVwIHRoZSBjb2xvcnMgZW5hYmxlZCwgYmVjYXVzZSBpdCdzCj4gPiBjdXJyZW50IGRpc3RyaWJ1dGlvbiBwb2xpY3kuCj4gCj4gQnV0IGFsbCBkaXN0cmlidXRpb25zIG5lZWQgdG8gYmUgYWNjZXNzaWJsZS4gIEl0IGlzIGEgcGVyLXVzZXIKPiBwcmVmZXJlbmNlLCBub3QgYSBwZXItdGFzayBvciBwZXItZGlzdHJpYnV0aW9uIHByZWZlcmVuY2UuICBTbyB1cHN0cmVhbQo+IGF0IGxlYXN0IG5lZWRzIHRvIHByb3ZpZGUgd2F5cyB0byBjb25maWd1cmUgaXQgcGVyIHVzZXIsIGFuZCBkb3duc3RyZWFtCj4gcHJvdmlkZSBhIHVuaWZvcm0gd2F5IHRvIGNvbmZpZ3VyZSB0aGUgdmFyaW91cyBzaGlwcGVkIHRvb2xzLgoKRnJvbSB0aGUgaWRlYSBpbiB0aGUgYmxvZyBwb3N0CihodHRwOi8va2FyZWx6YWsuYmxvZ3Nwb3QuZGUvMjAxNC8wNC90ZXJtaW5hbC1jb2xvcnNkLmh0bWwpLCB0aGUgdXNlciBzaWRlCnNlZW1zIHRvIGJlIGNvdmVyZWQgd2l0aCB0aGUgb3ZlcnJpZGUgY2FzY2FkZSBvZiAvZXRjL3Rlcm1pbmFsLWNvbG9ycy5kLyA8LQokSE9NRS8uY29uZmlnL3Rlcm1pbmFsLWNvbG9ycy5kLyA8LSAtLWNvbG9yPVguICBBbmQgdGhlIGRpc3RyaWJ1d!
 GlvbiBzaWRlCndvdWxkIGJlIGNvdmVyZWQgYnkgc2V0dGluZyBkZWZhdWx0cyBpbiAvZXRjL3Rlcm1pbmFsLWNvbG9ycy5kLyBhbmQgdGhlbgphbGxvd2luZyBwZXItdXNlciBzZXR0aW5ncyBpbiAkSE9NRS8uY29uZmlnL3Rlcm1pbmFsLWNvbG9ycy5kLyB2aWEgYSBHVUkKdG9vbC4gIFRoZSB0b29scyBzaWRlIHNob3VsZCBiZSBlYXN5IGVub3VnaCB0byBpbXBsZW1lbnQgdXNpbmcgdGhpcwpzdGFuZGFyZGlzZWQgc3lzdGVtLiAgSXMgdGhlcmUgYSBkZWZpY2llbmN5IGluIHRoZSBkZXNpZ24/ICBBcGFydCBmcm9tIG1heWJlCmEgd2F5IHRvIGVuYWJsZSByYXRoZXIgdGhhbiBqdXN0IGRpc2FibGUuCgpBbHNvLCBzaG91bGQgdGhpcyBjb25jZXB0IGJlIGRpc2N1c3NlZCB3aXRoIHRoZSBmcmVlZGVza3RvcC5vcmcgcGVvcGxlCihodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8veGRnKSBmb3IgcG9zc2libHkgZGVmaW5pbmcgYQpuZXcgZGUgZmFjdG8gc3RhbmRhcmQ/CgpDaGVlcnMsCgpFZHdhcmQKCgpQLlMuICBGb3IgcmVmZXJlbmNlLCBhbmQgY3Jvc3MtbGlua2luZywgdGhpcyB3YXMgZmlyc3QgYnJvdWdodCB1cCBvbiB0aGUKTWFnZWlhIGRldiBtYWlsaW5nIGxpc3Q6CgpodHRwczovL21sLm1hZ2VpYS5vcmcvbC9hcmMvZGV2LzIwMTUtMDIvbXNnMDA0MDguaHRtbApodHRwOi8vdGhyZWFkLmdtYW5lLm9yZy9nbWFuZS5saW51eC5tYWdlaWEuZGV2ZWwvNDMyNDk=