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.
cflatter@zia.aoc.nrao.EDU (Chris Flatters) (04/12/91)
> 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. OPEN LOOK uses a specific set of colours for its 3D effect: white: used for highlights on the NW side BG1: Openwindows.WindowColor in XView/Sun olwm BG2: reduce brightness of BG1 by 10-15% (used for recessed buttons) BG3: reduce brightness of BG1 by 50% (shadow on SE side) black: default text, window outlines etc. In Sun's implementation of OPEN LOOK BG1, BG2 and BG3 are always contiguous entries in the colormap with BG1 at the lowest index. This is probably true of any implementation of OPEN LOOK that uses olgx to provide 3D objects. In principle different groups of windows may have different BG1s but Sun's version of olwm does not support this at present. Chris Flatters
merlyn@attunix.att.com (Steve Humphrey) (04/23/91)
>> 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. > OPEN LOOK uses a specific set of colours for its 3D effect: > > ... [definitions of white, BG1, BG2, BG3, black colors] > > In Sun's implementation of OPEN LOOK BG1, BG2 and BG3 are always contiguous > entries in the colormap with BG1 at the lowest index. This is probably > true of any implementation of OPEN LOOK that uses olgx to provide 3D > objects. ... in Sun's XVIEW implementation, that is. The OLIT 2.5 implementation (provided by USL as their 4.0 release) uses a similar scheme to adhere to the OPEN LOOK spec.: Given a background color (*background in a resource file), OLIT computes BG2 and BG3, using the formulas given in the OPEN LOOK specification (also given in Chris Flatters' note). The XAllocColor routine is used, with the appropriate values of RGB computed from the RGB of *background. No assumption is made about where these colors lie in a colormap. The toolkit also computes ``BG0''. This is usually white, but on screens with limited colors (e.g. 16-color VGA), a white highlight looks too artificial next to a dark or saturated BG1, so we allow an ``off-white'' computed from BG1. With color-rich screens, and with good choices for BG1 (i.e. light pastels), BG0 is almost always white. This computation scheme works fine for color-rich screens or even 16-color VGA where the 16 colors include mostly shades of one color. For color-poor screens, though, the computations often produce the ``same'' color as BG1. To help out here, we provide a way to ``manually'' set BG0, BG1, BG2, and BG3. The *colorTupleList resource (class *ColorTupleList) is a comma separated list of 4-tuples, such as this: *colorTupleList: (yellow,red,brown,black),(white,yellow,orange,brown) Each tuple contains the colors in the order BG0, BG1, BG2, BG3. The OLIT toolkit, given a *background color, will look in the colorTupleList resource for a matching BG1. If found, the tuple provides the BG0, BG2, and BG3 colors. If not found, the computations above are used. On a color-rich screen, when OLIT clients are put next to XView clients, they will typically show the same colors for the 3D rendering, assuming the same, lightly-saturated background (BG1) in both clients. On a color-poor screen with no lightly saturated colors, the OLIT client can still show a 3D effect where the XView application can't. Steve Humphrey UNIX System Laboratories merlyn@attunix.att.com