csvsj@garnet.berkeley.edu (Steve Jacobson) (04/12/91)
Our X application runs in the MIT X environment. At various times we put up windows that have custom color maps. To minimize causing color problems for other windows and window manager decorations, we allow the user to specify via a resource colors he/she wishes to preserve, and when we build a custom color map we put those colors in the same pixel index as they were in the default map. To go from named colors to default color map pixel values, we use the Xt routine XtConvertAndStore(), which uses the X library routines XAllocColor() and XAllocNamedColor(). These two routines only return Pixel values of read only color cells. They go through the colormap, looking for an existing read only cell containing the requested color. If one is found, that pixel value is returned. If one isn't found, the routines try to allocate an unused map cell with that color in it. If successful, the pixel value of the newly allocated cell is returned. In Open Look, we run into a few problems. First of all, the only window manager color resources we can affect are OpenWindows.WorkspaceColor and OpenWindows.WindowColor. We can look in the defaults file to find the colors for these and then include them in our preserve list. When our custom colormap is installed, these two colors don't change on the screen in the workspace or on the window decoration borders. However, there are more colors involved than this. There's the color used to indicate input focus, and there are colors used to give the decorations a 3-d look. If Open Look doesn't put these colors in resources that we can find in a defaults file, then there is no way we can find out the color names or RGB intensities so we can add them to our preserve color list. We can get around this by using another preserve mechanism. We allow the use to specify pixel index values to be saved. So by trial and error, the user can figure out where the other window manager colors are on the map and save them. In practice, these values are at the front of the map, UNLESS the user uses the defaults editor to change colors during a session. For the rest of that session the colors could be anywhere. We run into a different kind of problem when trying to preserve a color used for the Window.Color.Background resource. It looks like Open Look allocates a read/write color cell to handle this, since our program ends up with a different pixel value than the one on the default map for that color. We could handle this problem also by finding the pixel value and preserving it that way. We're interested in any knowledge/experience people have with these issues. In my opinion, it's "bad citizenship" for Open Look to use colors without letting the user know what the associated resources or values chosen are. I think it's also out of line to allocate a read/write color cell for a window background color (if that is indeed what is happening). For what it's worth, we didn't run into these problems when we tried Motif on an IBM RS/6000. The documentation was poor, and we never found a default colors list, but at least we were able to determine and specify all the appropriate window manager color resources, and then preserve them in our custom color map.