On Thu, Apr 08, 2004 at 05:31:09PM +0200, Marc Lehmann wrote: > 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? :) It sounds like an expression of surprise. But I do see occasional reports of longstanding bugs. However, in the discussion so far, it is not clear whether you are referring to the text cursor or the mouse pointer. > Well, this colour (a reatively dark blue on vt100 and everywhere else) is > often used as background colour because it's dark. and it's still more readable for most people. This is the 3rd comment in 6 months. One pointed out a contrast problem with cyan. Being a resource value, it is of course configurable. > If you want a light blue as foreground, then you can always have a light > blue as foreground, as xterm offers high intensity blue. ...which is still readily distinguishable from the default 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). I'm told that I am also, and that in fact people who have trouble distinguishing the older blue from black are also defective. > So this change brings a small improvement for non-colour-blind and a > vast problem for others. Perhaps the reverse of that comment is more correct. > I still think that the majority of applications use blue as background > for blue being perceived as darker as other colours. Actually, the only workable blue background schemes I've seen use white for text. The other colors all are harder to read than using black or white backgrounds. > 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. But it's not standardized. > 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 I could revisit this issue. When I first looked at it (probably 1997), xterm was using Xt to lookup resource values automatically. Now it delays some of those til they're needed (so it would be possible to detect cases where a resource value was not set, and modify its default value dynamically). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Attachment:
pgphZA34t2Ovt.pgp
Description: PGP signature