tag 241717 - unreproducible
thanks
On Tue, Apr 06, 2004 at 04:10:52PM +0200, Marc Lehmann wrote:
> On Tue, Apr 06, 2004 at 02:21:11AM -0500, Branden Robinson <branden@debian.org> wrote:
> > tag 241717 + unreproducible moreinfo
>
> Just BTW: there is no reason to tag this as unreproducible, as you haven't
> tried to reproduce it but dismissed it because you assumed the mouse
> cursor is wm-controlled. You might have tagged it as solved or notabug or
> something similar (wich would have been wrong, but at least consistent
> with your response :)
>
> > thanks
> >
> > > The xterm mouse cursor is a thin line, under debians xterm, it's much
> > > thicker.
> >
> > The *mouse* cursor is not controlled by xterm, but by another program,
> > probably your window manager.
>
> This is wrong. If you don't believe me please ask somebody who knows more
> about X. The mouse cursor is application controllable and apps usually
> make ample use of that. xterm sets it to the insert cursor (or whatever is
> configured for xterm), sets the colours etc. and even has escape codes to
> control this appearance.
Sorry, you're right, and I had a brainfart here. I apologize.
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.
> > To be precise, the Debian default is "gray90" on "black". You can see
> > this in /etc/X11/app-defaults/XTerm-color.
>
> I was very imprecise with my use of "black" vs. "white" indeed, the
> point being more of dark-on-light bg vs. light on dark bg, or more
> precisely, using the same fg/bg colours for the mouse cursor as for
> the text.
>
> Nevertheless, the mousecursor is normally black-on-white (or
> black-on-gray90 if you like). Debian reverses the default colours for the
> text but leaves the mouse cursor colours black-on-white (or gray90) while
> correct colours are white-on-black (or gray90).
Oh, I see what you mean. The way old X documentation talks about this
is that the "background" of the X cursor is a "mask", and the foreground
is an inset image. The mask completely surrounds the cursor.
Okay, so you're bothered by the fact that the mask is visible by default
in Debian, but not on good old white-background xterms.
Huh. I can't remember anyone complaining about this before, and this
change has been in place for *years*. However, I use "unclutter", so
the large, prominent text-insertion-looking cursor never really gets in
my way.
> You can see the correct behaviour and correct appearance by starting xterm
> without te debian colours (white bg), or another terminal emulator such as
> rxvt-xpm or Eterm or pterm or just about anything else (I haven't found
> any emulator that does it wrong with the exception of rxvt-unicode, which
> is an old version which has been corrected upstream).
Yeah, I know what you're talking about now.
> > Perhaps you could put a window dump of xterm up on the web somewhere so
> > we could have a look at this?
> >
> > What you're describing doesn't sound like Debian's defaults at all.
>
> Here is an example:
>
> http://data.plan9.de/x.png
>
> The lower right terminal contains a much lighter blue (blue is often used
> as a background colour). The other terminals show more-or-less standard
> vt100 colours, the xterm shows a much more difficult-to-read combination
> (for me). The program used is alsamixer, but many other programs use this
> bg colour by default (mutt, irssi, epic4 I think etc..)
xterm refers to it as "color4", a resource of the VT100 widget.
I find this color, "DodgerBlue1", much easer to read on a
black-background xterm when using terminal fonts of very low weight.
Like the default "fixed" font, which is xterm's default.
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.
* use color resource setting from Debian package for xterm VT100
widget, since the choice of blues provides better contrast.
http://cvsweb.xfree86.org/cvsweb/xc/programs/xterm/XTerm-col.ad
(See the commit message for revision 3.2.)
I do agree that the contrast is better in the left window on your
screenshot, however you're using a heavily-weighted, thick font.
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 using xterm normally, and am using my own .Xdefaults for
> 10years+, which is why I didn't notice the problem so far. While working
> on rxvt-unicode I had a bug that kept the terminal from settting mouse
> colours, which I fixed (in version 2.7 btw). My own rxvt* config also
> defaults to white-on-black (gray80, actually ;), while both rxvt and
> rxvt-unicode default to black-on-white just like xterm.
>
> However, the mouse cursor in rxvt-unicode wasn't adjusted properly (that
> code was broken and commented out). After fixing this I tried xterm with
> the debian default config for the first time (thus the HOME=/tmp/empty
> to ensure my .Xdefaults aren't picked up (they are not loaded into the
> x-server, either)).
>
> I then noticed both the hard-to-read colours (which are from
> /etc/X11/app-defaults/XTerm-color) as well as the same "bug" regarding
> the mouse cursor (unlike rxvt-unicode, it's not neccessarily a code bug
> but a config bug, although it could be assumed that xterm should use the
> configured fg/bg colours for the mouse cursor by default, as rxvt-unicode
> does. xterm does not do this and needs manual configuration to match the
> configured colours. The default black-on-white config is consistent,
> while debian reversed only part of the colours and left others unchanged,
> resulting in a white background colou for the mousecursor and black for
> the text, creating an outline version of whatever cursor used).
Reviewing the xterm manpage, I see that the pointer cursor is
configurable by escape sequences (as you noted), by a command-line
option ("-ms"), and by the X resources pointerColor and
pointerColorBackground.
With respect to the latter:
pointerColor (class PointerColor)
Specifies the foreground color of the pointer. The default is
##XtDefaultForeground.##
pointerColorBackground (class PointerColorBackground)
Specifies the background color of the pointer. The default is
##XtDefaultBackground.##
I wonder if it shouldn't default to the VT100 widget's text foreground and
background colors instead.
What do you think?
> I assume that this is a just an oversight or a omission on part of the
> debian maintainer, nothing more, and not intended behaviour.
Yup.
> The changed colours, OTOH, are obviously intended behaviour, but most
> 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.
> The standard (vt100) colours are more-or-less standard among all terminal
> emulators (some might use not-quite-white for white, but the general
> brightness and look is extremely similar).
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.
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.
> Debians xterm (and only debains xterm AFAICS) changed at least one of
> these colours (maybe more). The problem is that programs assume the vt100
> colour set and due to the drastically changed brightness (apart from
> appearance) of the changed colour(s), programs often output hard-to-read
> 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.
> In addition, this colour change *is* a bug as the manpage documents the
> colours clearly, but the displayed colours are not in according to the
> manpage.
I agree that the manpage should be patched for Debian.
> To resolve this, either the manpage needs to be updated to conform to
> the debian "standard", or (preferably as this is a usability issue), the
> 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.
--
G. Branden Robinson | People are equally horrified at
Debian GNU/Linux | hearing the Christian religion
branden@debian.org | doubted, and at seeing it
http://people.debian.org/~branden/ | practiced. -- Samuel Butler
Attachment:
signature.asc
Description: Digital signature