[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#241717: xterm: various colour problems (mouse cursor color, text colours)



On Mon, Apr 12, 2004 at 07:33:58PM -0400, Thomas Dickey <dickey@radix.net> wrote:
> On Thu, Apr 08, 2004 at 05:31:09PM +0200, Marc Lehmann wrote:
>  
> >    framebuffer:  #0000aa (standard vga actually, and real vt100 AFAICR)
> 
> vt100's do not, never have done color.

The ones with the advanced video option had. Call them vt102, or
whatever you like, I do not care.

> A reasonable alternate choice (still improving contrast for blue/black) might
> for instance be blue2, which is a little brighter (0xee) than the value used by
> pterm.  On the other hand, it might not display well with a blue/white
> combination on a low-quality display (I recall some issues about that).

On low quality displays people will not use blue/white, as it is very
straining for the eyes to have white backgrounds anyways.

On Tue, Apr 13, 2004 at 10:15:51AM -0400, Thomas Dickey <dickey@radix.net> wrote:
> > The vt100 colours look very similar everywhere, so programs had ample time
> > to find combinations that work, as opposed to ones that do not work.
> 
> but as long as you insist on referring to vt100 colours, I'm regarding the
> report only as an attempt to annoy people.

Well, you can research this easily yourself. I don't care how you regard
my report, as you can check everything I said for yourself, and I hope
you did.

Disregarding a perfectly fine bugreport just because I am not 100% precise
in my naming conventions is rather idiotic, but it's you to chose. I am
absolutely sure that you understood my points, and you understood all
the problems I am talking about. The solution, or the way to proceed, is
entirely up to your decision (or the debian X maintainers).

If you are looking for reasons to disregard my report, there are easier
ways than being a hipocrite :(

On Tue, Apr 13, 2004 at 03:04:43PM -0500, Branden Robinson <branden@debian.org> wrote:
> > > > problem, not the terminal emulator, which, after all, just offers a fairly
> > > > standardized colour set.
> > > 
> > > But it's not standardized.
> > 
> > I would call that pretty much standardized. What you mean is probably
> > that there is no real standard the mandates that with force.
> > 
> > That is of course true. Neither the w3c nor the ietf nor... will care a
> > bit which exact colour is used in xterm or elsewhere :)
> 
> That's common practice, not standardization.

It is common practise, and also standardization. Please do not think
that only "official" standard bodies can create standards, that's not
what the word "standard" means (see, for example, "de-factor standards"
or "industry standards" which might or might not be standardized by a
standards body like iso, but are beverteheles standards, as long as they
are documented).

I think that arguing about words (as this is the level both of you are
approaching here) is not useful, and I have nothing more to day about this
issue.

I would be glad if you would discuss or decide according to the technical
issues and problems I brought up. Arguing about words or word usage is
secondary to the problem, and will neither help you nor me.

> With proper standardization comes expert advice.  I don't think the
> xterm color defaults, or the defaults used by other terminal emulators,
> were selected with the aid of expert advice.

True. And neither was expert advice sought when changing these. The
problem is that a large body of software has inherent knowledge of these
colours (by using them in certain combinations to get certain effects,
e.g. use red for warnings). Obviously it would be bad to give some
colour codes (former red) completey new colours.

It's much less bad to change them subtly, and I think the xterm colour
change is somewhere in the middle: It's not terribly problematic, but
certainly a drawback for common existing applications, while improving
the situation for some others.

My point is that this is unexpected, and it's not a very intelligent
idea to make colours incompatible in xterm compared to other terminals
or terminal emulators by changing readable combinations.

Existing terminals have lots of combinations that are marginally readable,
not readable, or well readable. The xterm change does not improve the
situation, it just changes it by making some combinations more readable
and others less.

And I argue precisely that this change is unexpected and not good, from a
standardization side, as apps must be rewritten with knowledge about xterm
colour combinations that are readable, as opposed to all other terminals.

And if I haven't made this completely clear: I do not care about rgb bit
values used for colours, I only care about readability, which, overall,
seems to have been decreased rather than increased by xterms changes.

> They were picked because they were color values close to some ANSI
> terminal standard (I don't know which one) -- and which could be easily
> encoded in a 4-bit colormap.

This is factually wrong.


> I think the colors in common practice were the product initially of
> technological constraints, and subsequently due to laziness, inertia,
> and code reuse.

Yes.

> That's not standardization.

Well, this is, unfortunately, exactly how standards get created most of
the time, by writing and documenting existing practise. I agree that
this is often not the best thing, but that's how it happens.

To convince you, here is (part of) the merriam-webster entry of "standard":

   3 : something established by authority, custom, or general consent as a
   model or example : CRITERION
   4 : something set up and established by authority as a rule for the
   measure of quantity, weight, extent, value, or quality

You idea of "standard" is limited to 4, but 3 also means "standard".

Yes, you can disregard merriam webster, language is not an absolute
thing.

The fine point is that even your definiton of "standard" would be the
only valid one, the principial issue in my report is completely
untouched for.

That is why I think that arguing about words as both of you start to do
is completely backwards. You can't claim I haven't been constructive, I
laid down my reasoning in as best a way as I can.

Claiming I am just trying to annoy you (TD) is quite uncalled for. Just
as you, I am working very hard to improve free software in general and in
this case debian (even if in this case just by writing a bug report). I
don't feel that I deserved your behaviour at all :(

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |



Reply to: