Subject: Re: Recent Changes - Shadow colors

From: Dan Espen <[email-masked]>
Date: Tue, 17 Nov 1998 09:25:20 -0500

Brad Giaccio <[email-masked]> writes:
> On Mon, 16 Nov 1998, Dan Espen wrote:
> > colors I was  asking for.  (There is  no message being produced to let
> > you know that.)
> > 
> > After I released some colors, I saw a fairly low contrast 3D effect,
> > but it wasn't bad.  Tracing showed:
> > 
> > Background        Shadow          Hilite
> > ==========        ======          ==========
> > 5151 5151 7878    3d08 3d08 5037  63ac 63ac a2a6
> > 
> > When  I get  a chance,  I'll  check out  the  numbers  out  of the old
> > algorithm.
> > 
> > --
> > Dan Espen                                Phone: (732) 699-5570
> 
> Dan, 
> that's much better now.  I grabbed your fixes to ColorUtils.c and that
> looks perferct, for me at least.  And I even started with no free colors
> left and it worked like a charm.

This exchange between Brad and myself was off the list.

Time to sum this up.

What we have  now  with this  new  shadow/hilite function is a  common
routine for creating three-D hightlights and  shadows, usable by fvwm2
and the modules.

While colors stay away from extremes, the colors produced are the
same as fvwm2 has been producing for a while.  What this new algorithm
buys us is better colors when the colors contain maxed out RGB values.
I tested these colors, with what looked like good results:

FF0000 Red
00FF00 Green
0000FF Blue
FFFF00 Yellow
00FFFF Cyan
FF00FF Magenta

(Middle tones still produce a more pleasing effect.)

I didn't test black or white, but looking at the code, and comments, I
don't see how it would 3D those colors.  (That doesn't bother me.)

Closely associated  with  the Shadow  logic,  is the color  allocation
logic.   I almost made color allocation   a "libs" subroutine, until I
realized that  when  color allocation fails   in  fvwm2, it   wants to
broadcast the failure to all modules using "fvwm_msg(ERR,...)".

I don't see how that  function will work in  a module. A module  would
have to send  a broadcast  request to fvwm2.   So, I've  put that idea
aside, for now.

> Thanks,
> Brad

Thank you.
--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tim Phipps <[email-masked]>
Date: Tue, 17 Nov 1998 14:41:39 +0000

> don't see how it would 3D those colors.  (That doesn't bother me.)

What I've seen motif do is to make the hilite colour darker than the
background when the background is very light, and make the shadow colour
lighter than the background when the background is very dark.  This
breaks the hilite > background > shadow look but does at least let you
keep all three colours visibly different.  I don't know how the motif
algorithm picks the threshold at which it flips, it doesn't appear to be
just a luminance number.  I've played with the CDE style manager colour
picker and you can set a saturation and luminance and then as you move
the hue around some hilite colours will be lighter and others darker. 
They must have paid a human factors person to come up with the rules.

I vote for keeping in sync with GTK, it makes swallowed GTK windows and
FvwmButtons look really nice if the shadow colours match.

Cheers,
Tim.