Subject: Re: to do for 2.4 (update 23)

From: Dominik Vogt <[email-masked]>
Date: Fri, 1 Oct 1999 02:09:45 +0200

On Thu, Sep 30, 1999 at 06:05:35PM +0100, Tim Phipps wrote:
> Dominik Vogt wrote:
> > 
> > Alright, the new parsing is in place.  The 'Colorset' command for
> > FvwmTheme now takes a comma separated list of options:
> 
> Great stuff, I've done a man page, it needs reviewing.

I have to revise my statement that it would be no problem
at all :-) Took me the whole evening because the code was
happliy assuming that the parts could not be set independently.

> > ---
> > There are two more issues that I did not resolve, and I
> > would be grateful if I don't have to do it.  First, since
> > all options are optional, we need to supply some default
> > colours if the user doesn't specify one.  All that is left
> > to do is to put the appropriate pixel values in the
> > structure - the logic is already there.  I have marked the
> > placed where to put the code with three exclamation marks.
> 
> I couldn't think of anything better than copying the colors from
> colorset 0. Colorset 0 is initially created by fvwm and contains the
> DefaultColors colors which default to black/gray.

Sounds like the perfect solution.  Is this mentioned in the
man page?

> > The second open issue are the hilight and shadow colours.
> > These used to be initialised with a colour based on the bg
> > colour (with 'average' background).  I don't understand why
> > we can't simply use GetShadow() and GetHilite() here.  I have
> > ifdef'ed two occurences of this logic.  If it's okay to use
> > Get...() these two paragraphs can be deleted.
> 
> These colors are calculated when FvwmTheme is using read/write colors.
> In this case the pixel values never changed (they are
> XAllocColorCells()'d when the colorset is created).  You can't use
> GetHilite() since it uses XAllocColor and returns a pixel.

Ah, I understand.  But shouldn't we have a modularized version
of Get...() that works on rgb values only?  I don't like the
code duplication in FvwmTheme.

> > ---
> > There was a bug in the calculation of 'average' background
> > colours with transparent pixmaps.  The pixmap first filled
> > the transparent part with the yet undefined background
> > colour, then the bg code calculated the average colour on
> > the random pixels :-) I guess I have fixed this.  I didn't
> > test the 'contrast' bit.
> > 
> Contrast is just calculated from the background color so this shouldn't
> need changing.

No, I meant I didn't test if 'contrast' still works since I
don't know exactly what it is supposed to do (i.e. which
colour is chosen based on the bg colour).

> > ---
> > I had to put back the mask bit in colour sets. I need
> > them to draw the transparent part of xpm backgrounds in the
> > background colour. Tim, please have a look at the current
> > colorset_struct. I had to put some FvwmTheme internal
> > members in there that are not communicated to the modules
> > but take up some space. Do you have a better idea how to
> > handle this?
> 
> I've put an ifdef in the structure definition so that only FvwmTheme.c
> can see the private parts. I don't know if this is the best way but it
> compiles.

Sounds okay to me.  One of the rare useful applications of
ifdef.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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, 05 Oct 1999 11:17:30 +0100

> Sounds like the perfect solution.  Is this mentioned in the
Yes.

> code duplication in FvwmTheme.
We could but it would only be used by FvwmTheme so I don't think it
would save any code.

> colour is chosen based on the bg colour).
It works on the red/green/blue components individually and sets each one
to be as far from the background value as possible.  This means it
chooses one of white, black, red, blue, green, cyan, magenta or yellow.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 5 Oct 1999 12:51:25 +0200

> We could but it would only be used by FvwmTheme so I don't think it

Now that I have taken a look at ColorUtils.c I see that the code
we need is already there.  To get the hilight colour you can
call

    color_mult(&c.red, &c.green, &c.blue, BRIGHTNESS_FACTOR);

(where c is a XColor struct) and 

    color_mult(&c.red, &c.green, &c.blue, BRIGHTNESS_FACTOR);

to get the shadow colour.  This is exactly what Get... do.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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]