All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Karel Zak <kzak@redhat.com>
Cc: kerolasa@gmail.com, "Dale R. Worley" <worley@alum.mit.edu>,
	"Pádraig Brady" <P@draigbrady.com>,
	mrmazda@earthlink.net, util-linux <util-linux@vger.kernel.org>
Subject: Re: tty[1-6]: colors a negative accessibility/usability trend
Date: Mon, 16 Feb 2015 04:35:33 -0500	[thread overview]
Message-ID: <20150216093533.GJ4075@vapier> (raw)
In-Reply-To: <20150216091043.GA11948@ws.net.home>

[-- 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 --]

  reply	other threads:[~2015-02-16  9:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12  9:45 tty[1-6]: colors a negative accessibility/usability trend Felix Miata
2015-02-12 11:04 ` Pádraig Brady
2015-02-13  3:21   ` Dale R. Worley
2015-02-13  9:21     ` Karel Zak
2015-02-13 10:33       ` Sami Kerola
2015-02-13 11:25         ` Karel Zak
2015-02-15 11:12           ` Mike Frysinger
2015-02-16  9:10             ` Karel Zak
2015-02-16  9:35               ` Mike Frysinger [this message]
2015-02-16  9:47                 ` Karel Zak
2015-02-16 10:32                   ` Samuel Thibault
2015-02-16 13:49                     ` Karel Zak
2015-02-27 13:48                     ` Karel Zak
2015-03-01 13:32                       ` Pádraig Brady
2015-03-01 15:14                         ` Peter Cordes
2015-03-02  8:59                         ` Karel Zak
2015-03-02  9:31                           ` Samuel Thibault
2015-03-02 11:03                             ` Karel Zak
2015-02-15 17:38         ` Dale R. Worley
2015-02-16  9:18           ` Karel Zak
2015-02-13 17:55       ` Bruce Dubbs
2015-02-12 13:21 ` Karel Zak
2015-02-12 13:56   ` Samuel Thibault
2015-02-12 14:38     ` Karel Zak
2015-02-12 15:25     ` Edward d'Auvergne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150216093533.GJ4075@vapier \
    --to=vapier@gentoo.org \
    --cc=P@draigbrady.com \
    --cc=kerolasa@gmail.com \
    --cc=kzak@redhat.com \
    --cc=mrmazda@earthlink.net \
    --cc=util-linux@vger.kernel.org \
    --cc=worley@alum.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.