csvsj@garnet.berkeley.edu (Steve Jacobson) (05/03/90)
Here is a bug report I sent to xbugs. The wonderful world of BlackPixel
and WhitePixel revisited.
VERSION:
R4
CLIENT MACHINE and OPERATING SYSTEM:
Sun SparcStation 1 running SunOs 4.0
DISPLAY TYPE:
Sun cg6
WINDOW MANAGER:
twm
AREA:
Xt
SYNOPSIS:
XtDefaultBackground and XtDefaultForeground may be useless when using a
non-default visual of class StaticColor or StaticGray
DESCRIPTION:
The function CvtStringToPixel() in Converters.c uses BlackPixelOfScreen()
and WhitePixelOfScreen() to supply contrasting colors for default
foregrounds and backgrounds. Since those two functions return pixel values
from the screens's default colormap, this works fine as long as the client
uses the default colormap.
If a client creates a custom map, then the colors for the pixel values
returned by the above functions may or may not contrast on the custom map.
For PseudoColor and GrayScale visual classes, it is reasonable to place
the responsibility on the client programmer to insure that contrasting
colors appear in the pixels or that the widget creation overrides
resource values to insure contrasting foregrounds and backgrounds. In my
opinion, the former strategy is the better one.
If a client uses a StaticColor or StaticGray visual THAT IS NOT THE DEFAULT
VISUAL, then the programmer has no opportunity to insure that contrasting
colors are used in the "black" and "white" pixels, since the color cells
are read only.
In the the mit color Sun server, the default visual is PseudoColor and
the "black" and "white" pixel values are 1 and 0. If a client uses the
non-default StaticColor or StaticGray visuals, colormaps created from both
of those visuals have very dark colors at 0 and 1. Thus, if the client
does not specify specific foreground and background colors, the client
comes up black, with foreground and background indistinguishable.
REPEAT BY:
Our application is too big to send. Send mail back if you can't figure
this out.
I believe the above explanation is clear. To verify, look at the code
in CvtStringToPixel() and check the StaticColor and StaticGray colormaps.
SAMPLE FIX:
2 alternatives:
1) Require/Suggest that non-default static visuals put "white" and "black"
in same pixel locations they are in the default colormap.
2) Have CvtStringToPixel() use the colormap argument to determine default
foreground and background pixel values. This could involve using
XAllocNamedColor() or XQueryColor().
Alternative 1 may be the best. There's probably a lot of people unhappy
about CvtStringToPixel() the way it is right now (including me), and any
change is not going to please everyone.