csvsj@garnet.berkeley.edu (Steve Jacobson) (03/14/90)
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.
csvsj@garnet.berkeley.edu (Steve Jacobson) (03/14/90)
Here's some further comments about the problem described in the previous posting. I remember doing some testing with the MIT server where a Shell widget created with a read/write colormap did not result in the protocol error, but instead in the "cannot allocate color entry" warning that you would expect (but maybe not desire). The difference between the two situations is the visual - default for the MIT, and non-default for X/News. Any insight into this problem will be appreciated.