Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Thu, Apr 08, 2004 at 01:19:07AM -0500, Branden Robinson <branden@debian.org> wrote:
> However, the appearance of the X cursor when inside an xterm window has
> not changed in my experience in the 6 years I've been maintaining this
> package for Debian.
Well, it's not really a major bug but a minor issue. I think it should
be fixed, but it's obviously somethig if a correctness issue (how it was
meant to be, or how other terminals handle it) not a usability thing.
> Huh. I can't remember anyone complaining about this before, and this
> change has been in place for *years*.
(Is that an argument? For what? :)
Fact is, it's incorrect, both from the standpoint of xterm (only some
of fg/bg was reversed) as well as from the standpoint of other apps,
terminals or not. They all use the same cursor, except xterm in default
config.
Wther there are masses of people complaining or not should certainly
influence the priority that this bug gets. One might even argue that the
new look is _better_ (I don't) and keep it, but it should receive some
thought at one point in time.
> I find this color, "DodgerBlue1", much easer to read on a
> black-background xterm when using terminal fonts of very low weight.
Well, this colour (a reatively dark blue on vt100 and everywhere else) is
often used as background colour because it's dark.
If you want a light blue as foreground, then you can always have a light
blue as foreground, as xterm offers high intensity blue.
The only "app" I know that uses the darker blue as fg is ls, however,
there are a multitude of apps that use it as bg (very old ones as well as
new ones, such as alsamixer).
Most combinations become unreadable to colour-blind people (it seems, at
least this is true to me, although I am not completely colour blind but
have a colour weakness).
> Like the default "fixed" font, which is xterm's default.
Thinner fonts only make this problem worse for me, as the area
decreases.
> In fact, the upstream XTerm maintainer, Thomas Dickey, appears to have
> agreed with my reasoning (as have many users), and changed the upstream
> defaults to look like Debian's.
I do not think it is fair to take a majority to decide for visually
impaired. After all, the majority of users doesn't suffer from this
problem. In contrast, it is rather easy to read the default dark blue on
black (for me), as opposed to almost anything on the new light blue.
So this change brings a small improvement for non-colour-blind and a
vast problem for others.
I still think that the majority of applications use blue as background
for blue being perceived as darker as other colours.
If an app uses it as fg and this is bad, then I think that app has a
problem, not the terminal emulator, which, after all, just offers a fairly
standardized colour set.
> I do agree that the contrast is better in the left window on your
> screenshot, however you're using a heavily-weighted, thick font.
Well, a thinner font makes it much worse for me.
> You might be able to win me over on the mouse cursor issue, but I'm not
> persuaded on this one.
>
> (Of course, if anyone reading this on debian-x would like to offer their
> opinions, please do.)
I am not personally insulted if you fix neither of these problems. I
stated my opinion, that it is a bug, but I am not terribly affected by it
(most occasions where i have to use xterm I don't need colour, and when I
need colour I am usually in front of one of my machines).
It's not of any priority either...
> pointerColor (class PointerColor)
> ##XtDefaultForeground.##
>
> pointerColorBackground (class PointerColorBackground)
> ##XtDefaultBackground.##
>
> I wonder if it shouldn't default to the VT100 widget's text foreground and
> background colors instead.
>
> What do you think?
>
I tend to agree. That is (I think) how rxvt does it and (definitely) how
rxvt-unicode does it. I have no idea how other terminals like pterm, Eterm
etc. do it. They are (on debian at least) gray-on-black, but the mouse
cursor colours _are_ "correct", wether their maintainers, their authors ir
the binaries themselves do it, I am not sure.
> > combinations are much harder to read to me (I have a very common form of
> > red-green blindness).
>
> Hmm. This is the first I've heard of the changed colors being an
> accessibility impediment.
Most people won't bother to report it, I'd guess, because for most
people it is a non-issue (not having problems because they don't depend
on the contrast) and for the rest it's a minor issue (it _is_ a minor
issue: I can change colours, and people who can't can just use another
terminal. As a matter of fact, xterm is probably not the most-used shell,
as it is in a somewhat detrimental state and the (much worse) konsole and
gnome-terminals come "standard" on most dekstops).
> Well, the Linux framebuffer console driver uses a shade of blue very
> similar to the one I made color4 use for the corresponding color, and
> *that's* a VT100 (technically VT220) emulator.
I can't reproduce that at all.
I just booted a knoppix, which uses fb, and looked at the 2.4.25
source. The shade of blue used for the framebuffer looks identical and (by
code) seems to be even darker than colours the majority of terminals use
(i.e. "dark" blue, although it's quite a light blue in fact).
framebuffer: #0000aa (standard vga actually, and real vt100 AFAICR)
gnome-terminal#0000aa
Eterm: #0000cc
rxvt: #0000cd
mlterm: #0000e6
pterm: #0000eb
konsole: #1818b2 (quite different, but still mostly the same blue)
xterm-debian: #1e90ff (drastically different colour, especially
with regards to contrast)
That clearly disagrees with what you claim. As you can see, they vary
considerably in the exact colour used, but it's always a real blue. The
only exception is xterm on debian that drastically changed at least that
colour to something not really blue either, but _much_ lighter and
giving a much lower contrast.
Maybe the kernel you used was especially patched to use another colour?
Or you use some user-space program that resets the colours after boot?
> It is this behavior of fbcon that inspiried me to change xterm's
> default, as I found that brighter blue much easier to read against the
> black background, and wanted xterm to be easy to read too.
Whatever inspired you, it's not the standard fbcon that is part of the
linux kernel (2.4.25 at least).
Please note that I don't say that change is inherently bad (if somehting
is broken for 20 years it should still be fixed), but that change brings
more bad than good, as all the other terminals mostly agree on the
shade of blue used and programs wil need to make exceptions to look
good/readable/as expected on xterm only (which they might well do and look
bad on most other terminals).
I think one mustn't change too lightly something that is such a widely
used de-facto standard. It took me only a minute or so to find out that
something is bad about xterm: I couldn't use alsamixer. And later some
other apps, but then I stopped trying.
Alsamixer is a good example. It assumes (not without good indication)
that blue contrasts good with red. However, xterm replaced that blue with
something resembling a light cyan (you can disagree with that description,
after all, my colour vision is not _that_ good and describing colours is
not the easiest thing for me :).
As a result, alsamixer is readable _everywhere_ except on debians xterm.
I think what needs to be changed is programs using bad colour
combinations, not the standard vt100 colour palette. Consider a similar
change in the TCP/IP protocol suite: some web-server is misbehaving and
breaking the http protocol.
The "xterm solution" would be to use another port number for the working
servers, while I would propose to leave working servers as they are and
instead fix the one web server that is causing the trouble.
The obvious (to me) reason is that changing the colour palette affects all
the "good" applications, while fixing the few apps that use bad colours
(colour-ls for example I would put into that group, at least with a thin
font. I sit in front of an LCD screen and don't have problems, but I guess
on CRTs the dark blue for directories might be annoying).
> > text on xterm while the same tetx looks readable everywhere else.
>
> Well, as I said above, this has precedent in fbcon, and is now the
> default upstream.
Well, as I said above, there seems to be no precedent and it makes it very
hard to use for visually impaired users, and disagrees with the _whole_
rest of the world.
> I agree that the manpage should be patched for Debian.
That solution is fine with me, if you ask me.
> > colours should be set to the same set of colours that every other terminal
> > displays, otherwise programs have no chance to use colours portably.
>
> I think you are overstating your case. Please adjust it in light of the
> facts I have now brought to your attention.
I honestly have no idea what you mean by that. I am not making fun of
you or anything, I just brought that to your attention, and you can fix
it in any way or like, either compatible with the rest of the world or
not.
Regarding the facts, the only verifiable fact I see is that debians xterm
uses a vastly different colour than everybody else seems to. I
completely agree wiht that, but that's what I am talking about, too.
I think I have now clearly and in every possible detail explained what
I wanted to explain. How you proceed is entirely at your discretion. My
"mission" is merely to bring this to your attention, and you agree that
_something_ should be done about this anyway.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Reply to: