Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsm!mls
From: merlyn@attunix.att.com (Steve Humphrey)
Newsgroups: comp.windows.x
Subject: Re:  Open Look tools background colors
Message-ID: <1991Apr23.145725.12859@cbnewsm.att.com>
Date: 23 Apr 91 14:57:25 GMT
Sender: mls@cbnewsm.att.com (mike.siemon)
Organization: AT&T Bell Laboratories
Lines: 60


>> 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