🚀 go-pugleaf

Our application is targeted at PseudoColor visuals. The X/News server on
color Suns has a PseudoColor visual, but the default visual is StaticColor.

As of R4, Xt supports widget creation that uses a nondefault visual. The
XtNvisual resource in the Shell widget can specify a nondefault visual.

Using this is not as simple as it might seem, because colormaps are associated
with visuals. A colormap associated with the non-default visual must be created
and the XtNcolormap resource must be set accordingly in the Shell widget.

(As an aside, the XtNcolormap resource is a great way to let the window manager
know about the desired colormap when you're using the default visual. You
can specify the desired colormap BEFORE the window manager maps the window.
In R3, you had to use XSetWindowColormap() AFTER the window was realized,
increasing the probability that the window manager might use the wrong
colormap.)

After a certain amount of struggle, we were able to run our PseudoColor
oriented application on a X/News server. However, we ran into problems
when we tried to use non-default foreground and background colors.

The command:

prog_name -fg blue -bg yellow

resulted in the error message:

X Error of failed request:  BadMatch (invalid parameter attributes)
Major opcode of failed request:  85 (X_AllocNamedColor)
Minor opcode of failed request:  0
Resource id in failed request:  0x600005
Serial number of failed request:  17
Current serial number in output stream:  17

We traced this to the XAllocNamedColor() call in the Xt function
CvtStringToPixel().

The colormap argument is the opaque colormap value associated with the colormap
we created using the PseudoColor visual. If, using dbx, we change the colormap
argument to the StaticColor default colormap, there is no error. 

We believe our problem occurs because XAllocNamedColor() won't work with
our colormap we created with read/write cells, rather than read/only cells.
It's a Catch 22, because we need to put colors into the cells in order
for CvtStringToPixel() to find a match, but CvtStringToPixel() will work
right only when it has a read/only colormap.

With the MIT server that offers the PseudoColor visual as the default
visual, we create all the widgets using the default read/only colormap,
then switch to a custom colormap, taking care that the foreground and
background pixel values have similar colors in the two maps. That way,
we can use our custom color map (for >245 color image display), but still
allow the user to set the widget foreground and background resources.

With the X/News server we can't do that because of the XAllocNamedColor()
behavior. The current behavior is unacceptable. For a PseudoColor read/write
map, XAllocNamedColor() should look through the map, seeking a match.
Of course, there may be some concern that the map entry is not read/only.
But clearly, the current protocol error behavior should be prevented.