Subject: Colorsets proposal

From: Tim Phipps <[email-masked]>
Date: Tue, 22 Jun 1999 18:27:58 +0100

I've been thinking about the current scheme of fvwm sharing graphics
contexts with modules and I think we should axe it before 2.4.  It's too
difficult to change a lot of the modules, it's not supported by Xlib and
it forces fonts to be shared as well as colors.

To replace it I propose the following:

1) fvwm continues to send a Default_Graphics config line to each modules
but the line will just contain the visualID and colormap that fvwm is
using.

2) fvwm manages a linked list of colorsets that starts with two members:
Colorset 0 is the same as DefaultColors, Colorset 1 is the same a
HilightColor.

3) A new command "Colorset" (or is it "ColorSet"?) can add to the list
or modify existing colorsets. The syntax is:

Colorset n fg bg [background_type [args]...]

n is the colorset number, fg and bg are either colors or - which means
no change, background_type is the same as the DefaultBackground command.

4) The colorsets are dumped to modules with their configuration and as
they are modified if the modules has selected dynamic configuration
updates.

5) Some library function to be written to grok these Colorset config
lines and manage a copy of the linked list of colorsets in each module.

6) Additional module config commands to be added to each module to
enable them to use the colorsets (e.g. *FvwmPagerWindowColorsets 2 3).

7) (optional) add colorset access to fvwm's menu and border code.

A Colorset structure would be:
typedef struct cset *Colorset;
typedef struct cset {
  Colorset next;
  Pixel foreground;
  Pixel relief;
  Pixel shadow;
  XID background;
  unsigned int number : 4;
  Bool bg_pixmap : 1;
  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;
};

Each colorset would take 48 bytes, there would be up to 16 of them and
they could handle pixmaps as large as 4095x4095 (which should be OK for
about 5 years).

Any objections?
Any volunteers?

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: Brad Giaccio <[email-masked]>
Date: Tue, 22 Jun 1999 14:48:33 -0400

>   unsigned int bg_height : 12;
Tim wouldn't we want to inlude fonts here as well, I thought the idea was to mirror the effect of CDE?
 
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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: Wed, 23 Jun 1999 15:49:17 +0100

> Tim wouldn't we want to inlude fonts here as well, I thought the idea was to mirror the effect of CDE?

I wanted to duck the issue of fonts.  I don't want this to get in the
way of the I18N patch and I wanted to make it simple enough that it
stood a chance of happening.  Hacking modules to make them capable of
font changing on the fly could be very difficult but hacking them to
change pixel values and do a refresh sounds a bit more practical.

If this gets the go-ahead and the modules get changed then we can think
about fonts.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 23 Jun 1999 13:21:05 -0400

> If this gets the go-ahead and the modules get changed then we can think

I can by that logic, I guess I didn't consider what could happen to a
layout if you went around changing the fonts, so your right just colors
make sense for now.

You have my vote.

Brad

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 24 Jun 1999 03:43:30 +0200

> but the line will just contain the visualID and colormap that fvwm is

Okay.

> Colorset 0 is the same as DefaultColors, Colorset 1 is the same as
> HilightColor.
 
See comments below.

> no change, background_type is the same as the DefaultBackground command.

Okay.

> they are modified if the modules has selected dynamic configuration

Okay.
 
> lines and manage a copy of the linked list of colorsets in each module.

Okay.

> enable them to use the colorsets (e.g. *FvwmPagerWindowColorsets 2 3).

Okay.

> 7) (optional) add colorset access to fvwm's menu and border code.

Mandatory. We can't make all this configurability and then ignore
it in the main module.

8) Touch all modules to make them use the colour sets if not
explicitly turned off.

> they could handle pixmaps as large as 4095x4095 (which should be OK for

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?

> Any objections?

I'm not completely happy with these colour sets. First of all I can not
see the exact use model behind them, or perhaps I am too preoccupied with
the solution I have myself. For example I use five different colours
in my FvwmPager from an eight colour palette. The same colours are used
in various other places for different purposes. I don't understand why
we have to say that the first colour of the set is a foreground colour
and the second is a background colour. That seems to limit my choice
how to use them.

 - I can't use a background colour for foreground and vice versa because
   I don't have the proper Hilight and Relief colours.

 - What can I do if I want to use, say the background colour from set 5,
   but I got a pixmap?

 - We'll waste too many colours for reliefs and hilights that are never
   used.

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.

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

 - 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];
   }

All your ideas how to actually implement this look good to me.

> Any volunteers?

I am willing to help, but I won't do everything.

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]