Subject: Re: Colorsets proposal

From: Tim Phipps <[email-masked]>
Date: Wed, 14 Jul 1999 12:29:37 +0100

Dominik Vogt wrote:
> 
> On Tue, Jun 22, 1999 at 06:27:58PM +0100, Tim Phipps wrote:
> > A Colorset structure would be:
> > typedef struct cset *Colorset;
> > typedef struct cset {
> >   Colorset next;
... deleted
> > };
> >
> 
> I count only 24 bytes. You have counted the bit fields as 32 bit. Why
> use a list if there can be only 16 colour sets?

I agree, I think an array will be faster assuming that the number of
colorsets will only change rarely if (maybe never).
> 
> > Any objections?
> 
> I think background pixmaps should be handled separately from colour sets.
> Here is what I propose:
> 
>  - Make a single colour set with e.g. 16 colours.

I'd like it to be variable so that you could have very few if colors are
tight

> 
>  - Dont send hilight/relief colours. They can be easily calculated by
>    the lib function. On the other hand we will never have configurable
>    hilight/relief colours if we do it this way (although I don't like
>    the idea anyway).

The other reason to send hilight/relief pixels is to match your desktop
clients better.  If you use mostly Gnome then it would be nice if the
hilight/relief pixels were calculated with the Gnome algorithm.

> 
>  - Make certain statements about the colour sets we would supply, e.g.
>    colour 0 is the default background, colour 1 is the default foreground
>    (used for all text), 2 is the hilight colour, 4 is the menu background,
>    5 the menu item hilight background, 6 the colour for shaded entries,
>    7/8, 9/10 are pairs of similar colours, one bright and one darker,
>    11 and 12 are colours quaranteed to give a nice, smooth gradient in
>    conjunction with 7-10, 13-15 are colours with a red/green/blue tint.
>    The user could redefine any of these:
> 
>      SetColour 7 green
> 
>    typedef struct cpalette *Palette;
>    typedef struct cpalette {
>      struct {
>        Pixel colour;
>        Pixel hilight_colour;
>        Pixel relief_colour;
>        unsigned has_hilight_colour : 1;
>        unsigned has_relief_colour : 1;
>      } cset[16];
>    };
> 
>  - The modules are preconfigured to use colours 0-6 for their default
>    look. This restriction to 7 colours ensures that we may restrict
>    the palette to fewer colours. If you don't have lots of colours
>    to spare you can disable sending of the hilight and relief colours.
>    You can use a library call to get the appropriate relief of hilight
>    from a colour. If the corresponding flag is set the function returns
>    the colour from the structure, if not it calculates the colour with
>    the usual mechanism.
> 
>  - We have a similar method to convey information about up to four
>    background pixmaps. Pixmap 0 (if defined) is used as the background
>    pixmap for the main application window while 1-3 can be user defined.
> 
>    struct dflt_back *Backgrounds;
>    struct dflt_back {
>      struct {
>        Pixmap pixmap;
>        Bool bg_keep_aspect : 1;
>        Bool bg_stretch_x : 1;
>        Bool bg_stretch_y : 1;
>        unsigned int bg_width : 12;
>        unsigned int bg_height : 12;
>      } back[4];
>    }
> 

Sorry for quoting the whole of this, I didn't want to just snip out
bits.  I  think you are right that we will will have to have some
convention for what the colors mean but I'd like to keep it as flexible
as possible.  I don't think we should fix the size.  I would like to
keep pixmaps with the color sets though as I feel that they will be used
with hilight/relief colors and that the average tone of a pixmap will be
similar to the background color of its colorset.  I agree that pixmaps
should be separate from the background pixel. How about this as a
structure:

{
  Pixel fg, bg, hilight, shadow;
  Pixmap pixmap;
  unsigned int fiddly bits : ...;
}

The pixmap would be optional.  I think that for simplicity we should
always have hilight and shadow pixels, if your colormap is restricted
you should use fewer colorsets.

I've written a module that implement this. It takes dynamic config lines
line FvwmAnimate and also listens to SendToModule commands.  It converts
the text lines to colorset_struct's and sends a Colorset command to fvwm
whenever a colorset changes.  What fvwm should do is to broadcast the
Colorset line back out to all modules so they can update their copies of
the colorsets and redraw themselves.  

What I think fvwm should do is to just create Colorset[0] with the
DefaultColors command.  I'd like to remove the DefaultBackground command
from fvwm before 2.4 as it doesn't do much and might imply that fvwm
will be doing the colorset stuff in the future. I'd like to keep
colorset management in a module so that it is possible to plug in a GTK
version (or just modify FvwmGTK) that converts GTK themes into fvwm
colorsets.

After that we can work on the modules to get them to use the colorsets. 
After that we can think about fvwm itself using them for menus and
borders.

Should I check in the module? There's also some library functions and it
would move some stuff from fvwm into the library.

Cheers,
Tim.
--
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: Dominik Vogt <[email-masked]>
Date: Wed, 14 Jul 1999 16:53:16 +0200

On Wed, Jul 14, 1999 at 12:29:37PM +0100, Tim Phipps wrote:
>...

I've no time now. I'll comment on your mail later.
 
> Should I check in the module?

Of course, go ahead.

> There's also some library functions and it

The lib should hold as much functionality as possible.

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]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 14 Jul 1999 18:25:00 +0200

> I'd like it to be variable so that you could have very few if colors are

Yes. Only the first few colours should be mandatory.

> hilight/relief pixels were calculated with the Gnome algorithm.

Hm, okay. I have no stron feeling here. The number of colour can grow
pretty fast if each colour is accompanied by two others.

> I  think you are right that we will will have to have some
> as possible.

> I don't think we should fix the size.

Okay. The was only the logical conclusion of saying that there would
be only 16 colour sets. An arbitrary number is more flexible.

> I would like to
> similar to the background color of its colorset.
> 
> I agree that pixmaps

But a pixmap is restricted in the way you can use it. A foreground
pixmap does not make sense. I wouldn't link a background to a
foreground at all. Foreground colours don't need hilight or
shadow or background colours nor a background pixmap. They can stand
alone. Furthermore you will be unable to combine the foreground colour
from set 3 with the background colour/pixmap from set 5 (for example).
And why shouldn't you be able to combine forground 1 with foreground 2?

     struct {
       Pixel colour;
       Pixel hilight_colour;
       Pixel relief_colour;
       unsigned has_hilight_colour : 1;
       unsigned has_relief_colour : 1;
       unsigned is_pixmap : 1;
       unsigned more_pixmap_flags : ...;
     };

In above struct you can define a foreground colour by not setting
the two flags. If the flags are set and the colour is used as a
background, the hilhigt/relief colours are used (if the flags are
not set the colours can be calculated).

I could imagine a union of a pixmap/colour member:

     struct {
       union {
         Pixel colour;
         Pixmap pixmap;
       } u;
       Pixel hilight_colour;
       Pixel relief_colour;
       unsigned has_hilight_colour : 1;
       unsigned has_relief_colour : 1;
       unsigned is_pixmap : 1;
       unsigned more_pixmap_flags : ...;
     };

So you may link a background pixmap with hilight/relief colours.
My only concern is that this probably will confuse the user. From
the user's point of view a colour and a pixmap are entirely different.

> the colorsets and redraw themselves.

I wouldn't concern fvwm with colour set management at all (except that
fvwm has a command to set the colour sets it uses internally). The
theme module could simply ask fvwm to 'forward' a message to all modules
(excluding itself).

> will be doing the colorset stuff in the future.

> I'd like to keep

I like that idea :-) This way we won't have to write the themes
specifically for fvwm. Would it be worth the effort to make the theme
module GTK theme compatible right away (perhaps starting with a
partial implementation)?

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Fri, 16 Jul 1999 18:03:58 +0100

>        unsigned more_pixmap_flags : ...;

I think you're right about having pixmaps seperate from background
colors.  I've just checked in FvwmTheme and it has the following struct
{
  Pixel fg, bg, hilite, shadow;
  Pixmap pixmap;
  extras...
}

The pixmap is optional and you don't have to set the foreground or
background colors (just use "-"), they default to 0 if you don't set
them.
> theme module could simply ask fvwm to 'forward' a message to all modules

It will need a new command (Colorset) so that fvwm can make a copy for
it's own use and then broadcast it to all the other modules as an
M_CONFIG_INFO message. I thought this would be better than using
"SendToModule * Colorset..." as that would require modules to handle
M_STRING as well as config lines.

> Would it be worth the effort to make the theme

I'd like to keep FvwmTheme as simple as possible so that someone else
can use it as a basis for other toolkit versions (GTK, CDE, KDE?).

Cheers,
Tim.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 17 Jul 1999 10:14:29 +0300 (IDT)

> background colors (just use "-"), they default to 0 if you don't set

Am I missing something here? For what black-on-black combination is good?
I think, the default background can be gray or anything but unvisible.
Say, I don't define FvwmScroll attributes and get black-on-black
scrollbars, this is more than annoying.

Regards,
Mikhael.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 20 Jul 1999 14:47:55 +0100

> I think, the default background can be gray or anything but unvisible.

It's no good for anything but you will only get black on black if you
access a colorset you haven't defined.  I'm planning on making the
default colorset be 0 and having fvwm2 manage colorset 0 with the
DefaultColors command.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 20 Jul 1999 14:53:46 +0100

> module GTK theme compatible right away (perhaps starting with a
Well, that would prevent users who don't have GTK from using colorsets. 
FvwmTheme is complete now (apart from bugs of course) so I think it
would be better to take bits of it and put it into FvwmGTK.  I don't
know GTK at all so I can't help here.

I am thinking of a CDE port though but I'm having trouble finding a spec
for the Color Object.  Does anyone know how CDE does it color sharing
stuff and is there any (freely available) code for accessing he shared
colors?

Cheers,
Tim.