On Thu, Apr 08, 2004 at 01:19:07AM -0500, Branden Robinson <[EMAIL PROTECTED]> 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 +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |