Subject: core dump in colorset.c

From: tim phipps <[email-masked]>
Date: Tue, 07 May 2002 14:28:19 +0100

Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-40 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int

FVWM Version:	2.5.2
FVWM_MODULEDIR:	/u/phippst/sunos/libexec/fvwm/2.5.2
FVWM_DATADIR:	/u/phippst/sunos/share/fvwm
FVWM_USERDIR:	/u/phippst/.fvwm

Description:
	I get a core dump when executing this line:
Colorset 0 DGradient 100 #0f0f9f #0000ff, bg Average, fg Contrast, sh #0f0f9f, hi #0000ff
	The stack trace is:
(gdb) where
#0  0x3028c in parse_colorset (n=0, line=0xc4f81 "") at colorset.c:665
#1  0x45174 in CMD_Colorset (cond_rc=0xefffe280, eventp=0xab02c, w=54, fw=0x0, 
    context=8, 
    action=0xc4f31 "0 DGradient 100 #0f0f9f #0000ff, bg Average, fg Contrast, sh #0f0f9f, hi #0000ff", Module=0xefffe1e8) at builtins.c:2240
#2  0x5a504 in execute_function (efa=0xefffe1d0) at functions.c:1394
#3  0x5a6b8 in old_execute_function (cond_rc=0xefffe280, 
    action=0xc5a00 "Colorset 0 DGradient 100 #0f0f9f #0000ff, bg Average, fg Contrast, sh #0f0f9f, hi #0000ff", fw=0x0, eventp=0xab02c, context=8, Module=-1, exec_flags=0, 
    args=0xa8c00) at functions.c:1467
#4  0x5b1c8 in execute_complex_function (cond_rc=0x0, eventp=0xab02c, w=0, fw=0x0, 
    context=8, action=0xa8c00 "", Module=0xefffe450, desperate=0xc4a90)
    at functions.c:1973
#5  0x5a560 in execute_function (efa=0xefffe438) at functions.c:1413
#6  0x5a6b8 in old_execute_function (cond_rc=0x0, action=0xefffe4d8 "my_look_ramp", 
    fw=0x0, eventp=0xab02c, context=8, Module=0, exec_flags=0, args=0xa8c00)
    at functions.c:1467
#7  0x66ff0 in run_command_stream (f=0xab430, eventp=0xab02c, fw=0x0, context=8, 
    Module=0) at read.c:143
#8  0x67158 in run_command_file (filename=0x0, eventp=0xab02c, fw=0x0, context=8, 
    Module=0) at read.c:218
#9  0x672c4 in CMD_Read (cond_rc=0x0, eventp=0xab02c, w=54, fw=0x0, context=8, 
    action=0xba2cd "'/u/phippst/.f/fvwm2rc.m4.log'\n", Module=0xefffeaf8)
    at read.c:270
#10 0x5a504 in execute_function (efa=0xefffeae0) at functions.c:1394
#11 0x5a6b8 in old_execute_function (cond_rc=0x0, 
    action=0xb9f18 "Read '/u/phippst/.f/fvwm2rc.m4.log'\n", fw=0x0, eventp=0xab02c, 
    context=8, Module=0, exec_flags=0, args=0xa8c00) at functions.c:1467
#12 0x51e64 in ExecuteModuleCommand (w=0, module=0, 
    text=0xb9f18 "Read '/u/phippst/.f/fvwm2rc.m4.log'\n") at module_interface.c:680
#13 0x53740 in ExecuteCommandQueue () at module_interface.c:1678
#14 0x4bd78 in My_XNextEvent (dpy=0xaeb08, event=0xab02c) at events.c:3366
#15 0x4b980 in HandleEvents () at events.c:3171
#16 0x61cb4 in main (argc=1, argv=0xeffff2e4) at fvwm.c:718
(gdb) print cs
$1 = (colorset_struct *) 0xbafc8
(gdb) print cs->pixmap
$2 = 25165911
(gdb) print cs->picture
$3 = (FvwmPicture *) 0x0

--
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: Tue, 7 May 2002 16:08:44 +0200

> Colorset 0 DGradient 100 #0f0f9f #0000ff, bg Average, fg Contrast, sh #0f0f9f, hi #0000ff

Fixed.  Olivier, please take a look at colorset.c.  There were a
number of bugs with the cs->picture structure (accessing members
when it was NULL, comparing the pointer with 'None' instead of
NULL, checks in 'if' bodies where cs->picture wasn't used at all).
I'm not sure I've done everything right.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Olivier Chapuis <[email-masked]>
Date: Tue, 7 May 2002 22:22:13 +0200

> I'm not sure I've done everything right.

Yes, the core dump was my fault. I was/am a bit confused with
average bg and tinting. I recheck again and I've fixed an other
possible core dump (related to bitmap). I hope that everything
is ok now.

About average and tinting. Tint/TintMask allows to tint a pixmap,
my pbs is: do we have to compute the average bg after tinting
or not. With Tint, as the bg is also tinted, it seems that we have
to compute the average bg before tinting (but sh/hi maybe "wrong")
as with TintMask nothing is clear for me. So I take the simple
way: average bg is computed from the original pixmap, that's all.
Any other suggestions?

About bitmap I think it will be good to be able to define the bg and
the fg of the bitmap. The bitmap currently used the fg and bg color
and this gives unreadable text (if you do not use a tint). Any
objection for a bitmap_bg and a bitmap_fg options to the colorset
command?

Others ideas:
- Add an fg_alpha option : with xft rendering we can apply an alpha
channel to the text. Maybe good for "greyed" menu colorset and buttons
in IconMan which represent an iconified window.
- Add an Pixmap_alpha option: to put the pixmap in a translucent way
on the bg.
- Add an IconTint option: when we have to display a mini icon (or
an icon) on a colorset background the (mini) icon is tinted. May be
good again with greyed menu colorset and buttons in IconMan which
represents an iconified window (IconTint white 30).

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 7 May 2002 22:43:08 +0000

> way: average bg is computed from the original pixmap, that's all.

I think it may be like this: bg is not reevaluated after Tint commands.
If "bg Average" follows Tint, the modified pixmap is taken into account.

> objection for a bitmap_bg and a bitmap_fg options to the colorset

I have no real objection, but I would rather prefer to add support for
symbolic color names in xpm pixmaps. I.e. support xpm, not limited xbm.
The names that CDE supports would be a good start (bottomShadowColor is
sh, topShadowColor is hi, I am not sure about names they use for fg and
bg), and all colorset colors may be handled, not only the main four.

I can see a need in additional colors per colorset. Say, something that
could be used in Vector buttons, currently only fg, bg, sh and hi allowed.
So, we may add sh_vector, hi_vector. I prefer on-purpose color names to
abstract ones, i.e. color needed for vector buttons sounds more appealing
to me than color used by any bitmap defined in this colorset (there may be
several images per colorset with rendering implemented).

> in IconMan which represent an iconified window.

I hope I understand it right that fg_alpha is percents, not color.

> - Add an Pixmap_alpha option: to put the pixmap in a translucent way

I suggest to add AlphaPixmap that gets 2 arguments, alpha and pixmap.
So we have solid (destructive) bg, using *Gradient, Pixmap or Plain,
and a list of pixmaps that are applied one by one to the solid bg.
Any solid bg option removes all AlphaPixmap-s previously defined.

Or maybe only one such AlphaPixmap should be allowed?

Does Alpha*Gradient make sence? :) Maybe just AlphaColorset with 2 numeric
arguments? Anyway, I think that Pixmap_alpha option with one argument is
not a solution.

> represents an iconified window (IconTint white 30).

Yes, it could be a property of colorset.

Another idea. There was a request to add shadow to texts, I thought about
a fg_shadow color property of colorsets. Can this feature be handled by
FlocaleDrawString?

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 8 May 2002 07:28:29 +0200

> bg), and all colorset colors may be handled, not only the main four.

Hum, I do not know this CDE stuff. Can you be more precise?

> several images per colorset with rendering implemented).

I am agree that these  bitmap_bg and a bitmap_fg options are not good
ideas. But what is your suggestion?

> I hope I understand it right that fg_alpha is percents, not color.

Yes. In fact it seems that we can just allows a percent after the fg
color: fg black 60.
 
> Or maybe only one such AlphaPixmap should be allowed?

I think only one AlphaPixmap is enough, but if we go this way
the alpha is not really the problem. In fact you think about
an Add{,Tiled,Aspect}Pixmap. Again with or without this Add*Pixmap
option the alpha percent (in any case) can be passed as the last
argument of the *Pixmap option: Pixmap foo.xpm 77.
So what I suggest is to pass the alpha as just explained and add
Add{,Tiled,Aspect}Pixmap options which can add only _one_ pixmap
(for simplicity). Really I think that 2 images is enough in a
colorset: a full background + an image with a mask/alpha.

> a fg_shadow color property of colorsets. Can this feature be handled by

Yes it can be (and FvwmScript can already do it if I well understand
the feature). This needs work however: passing the colorset and take
care of the height and width (add 1 pixels).
So fg_shadow is not set by default and have a special key word sh
to use the sh color and is destructed by fg_shadow without argument
(but not by a simple fg ?).

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 8 May 2002 10:12:57 +0200

On Tue, May 07, 2002 at 10:22:13PM +0200, Olivier Chapuis wrote:
> as with TintMask nothing is clear for me.

Can you post a few examples that demonstrate the new features?

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 8 May 2002 10:14:49 +0200

> > bg), and all colorset colors may be handled, not only the main four.

Now *that* would be a cool feature.  I've been using FvwmCpp for
years so I can have palettes (and font lists) with symbolic names.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 8 May 2002 10:21:35 +0200

On Tue, May 07, 2002 at 10:43:08PM +0000, Mikhael Goikhman wrote:
> So, we may add sh_vector, hi_vector.

I don't like the idea over overloading individual colour sets with
lots of colours.  Tim and I discussed that back then when he wrote
FvwmTheme cand came up with the four colour structure we have now.
Mikhael, what you are probably seeing a colour set as a kind of
'theme' whereas I see it as a colour pair with options.  I agree
that there may be a need for more complex theme like structures.
But I'd rather see them as a layer on top of colour sets.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 8 May 2002 12:20:45 +0200

> Can you post a few examples that demonstrate the new features?

If it is the Tint feature you are intersted on here an example:

Colorset 50 TiledPixmap background/fvwm-flying.xpm, NoTint
Colorset 51 TiledPixmap background/fvwm-flying.xpm, Tint blue 20
Colorset 52 TiledPixmap background/fvwm-flying.xpm, Tint yellow 20
Colorset 53 TiledPixmap background/fvwm-flying.xpm, Tint black 30

DestroyModuleConfig FvwmBacker: *
*FvwmBacker: Command (Desk 0) Colorset 50
*FvwmBacker: Command (Desk 1) Colorset 51
*FvwmBacker: Command (Desk 2) Colorset 52
*FvwmBacker: Command (Desk 3) Colorset 53

So one xpm and 4 differents backgrounds for the 4 desks I use. 
Now an example where average/contrast come into play with tint:

# standard item
Colorset 17 fg contrast, bg average, \
	TiledPixmap background/stone.xpm, NoShape
# active item
Colorset 18 fg contrast, bg average, \
	TiledPixmap background/stone.xpm,  Tint red 30, NoShape
# iconified item
Colorset 19 fg contrast, bg average,  \
	TiledPixmap background/stone.xpm,  Tint white 30, NoShape
# pointed item
Colorset 20 fg contrast, bg average,  \
	TiledPixmap background/stone.xpm, NoShape
# modules special background
Colorset 12 fg black, bg rgb:80/A0/A0, \
	Transparent, NoShape 

*FvwmIconMan: *colorset		12
*FvwmIconMan: *iconcolorset	19
*FvwmIconMan: *plaincolorset	17
*FvwmIconMan: *selectcolorset	20
*FvwmIconMan: *focuscolorset	18
*FvwmIconMan: *focusandselectcolorset 20

So again one xpm and various colors. plain iconman buttons are
ok. But, at the present time, others does not have good fg,sh and hi
colours as stone.xpm gives a dark average bg colors and the corresponding
sh, hi and contrast colors are computed from this colors. For example
all contrast fg colorset are almost white which is not correct for colorset
19 which has grey bg in the average.

So it seems clear that average should be computed after tinting,
but this is not so simple to implement ... I will try to do something.

Olivier

PS: the two xpm used come from fvwm-themes image/background/

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 8 May 2002 13:14:46 +0200

> 19 which has grey bg in the average.

Very nice.  However, FvwmIconMan does not refresh the transparent
parts of the background when they are obscured and revealed again.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 8 May 2002 13:40:17 +0200

> parts of the background when they are obscured and revealed again.

I cannot reproduce this. Do you use the ParenatlRelativity style?
This style must be set for any apps which use a transparent colorset.
I've a plan to do this automaticaly.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 8 May 2002 14:27:38 +0200

> I've a plan to do this automaticaly.

Actually, I just added your config on top of mine:

*FvwmThemeColorset 2 fg red, bg green
*FvwmThemeColorset 6 fg red, bg blue, cgradient 20 yellow orange

Style FvwmIconMan NoTitle, Sticky, NoHandles, Icon toolbox.xpm
Style FvwmIconMan WindowListSkip, CirculateSkip
*FvwmIconMan*Action Mouse 3 N sendcommand close
*FvwmIconMan*FollowFocus true
*FvwmIconMan*Font 5x7
*FvwmIconMan*Format "%t"
*FvwmIconMan*ManagerGeometry 2x5
*FvwmIconMan*Resolution page
*FvwmIconMan*Title ""
*FvwmIconMan*UseWinList true
*FvwmIconMan*Action Mouse 2 N sendcommand Focus
*FvwmIconMan*Colorset 6
*FvwmIconMan*FocusColorset 2
*FvwmIconMan*FocusAndSelectColorset 2
*FvwmIconMan*PlainColorset 6
*FvwmIconMan*SelectColorset 6
*FvwmIconMan*TitleColorset 6
*FvwmIconMan*FocusButton up
*FvwmIconMan*PlainButton up
*FvwmIconMan*SelectButton flat
*FvwmIconMan*FocusAndSelectButton flat
*FvwmIconMan*TitleButton flat

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 8 May 2002 14:30:02 +0200

> Actually, I just added your config on top of mine:

Again you should add

Style FvwmIconMan ParentalRelativity

(and restart IconMan) so that transparent colorset can work.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 8 May 2002 14:50:30 +0200

> (and restart IconMan) so that transparent colorset can work.

Ah, cool, I see.  Sorry if I'm asking dumb questions.  I didn't
test much of the new functionality you and Mikhael have written in
the last months.  One thing that doesn't work though:  when you
start - say - FvwmButtons with a transparent colour set, but
without ParentalRelativity:  Cover it with a window, then reveal
it again.  The thransparent parts are not redrawn.  Now switch to
ParentalRelativity.  The transparent parts are still not redrawn.
This is done only when they are exposed again.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 8 May 2002 16:34:30 +0200

> This is done only when they are exposed again.

Yes, ParentalRelativity is not dynamic. I think that it is not
a new miss feature. Tim?

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 8 May 2002 21:19:51 +0000

> But I'd rather see them as a layer on top of colour sets.

I see a colorset as the only way to define colors inside a rectangle box.
I don't think that 4 main colors are enough for all needs. IMHO, it is
sometimes better to extend a colorset a bit if this solves a class of
problems than to use a new colorset just for one single color (other 3
colors and background image are unused).

There is no much need for sh_vector and hi_vector, they were examples.
Although they don't consume more than some bytes and have good defaults.

But do you have anything against adding fg_shadow color (or fgsh)?

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 8 May 2002 22:41:41 +0200

> Yes, ParentalRelativity is not dynamic. I think that it is not

Couldn't you simply force a refresh of the window when
ParentRelativity becomes set?

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: Dominik Vogt <[email-masked]>
Date: Thu, 9 May 2002 00:48:28 +0200

> But do you have anything against adding fg_shadow color (or fgsh)?

No, not at all.  I've no problem as long as the colour in the
colour set are usable regardless of the context (you could use a
shadow colour anywhere where text is drawn).  On the other hand,
I wouldn't like to have - for example - icon specific colours in
the colour set.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 8 May 2002 22:48:39 +0000

> Hum, I do not know this CDE stuff. Can you be more precise?

I don't know it either, but I can imagine what it is by looking at xpms.
CDE xpms use symbolic names, so changing CDE color schemes changes
symbolic image colors, this way images may include 3d elements using
shadow/hilight colors.

I did some search and here is some info (the second is in German):

  http://www.w3.org/People/danield/xpm_story.html
  http://www.remote.org/sven/CommonDesktopEnvironment_CDE_.html

> ideas. But what is your suggestion?

Maybe "*Bitmap xbm fg bg" option similar to *Pixmap?

> Yes. In fact it seems that we can just allows a percent after the fg

Maybe. In any case I think that fg with one argument should reset alpha.
On the other hand a separate fg-alpha option would allow something like:

  SendToModule FvwmPerl eval unlock(); \
    foreach $a (1 .. 100) { command("Colorset 1 fg-alpha $a"); }

:-)

> colorset: a full background + an image with a mask/alpha.

How about this:

  *Pixmap foo.xpm          # defines destructive background, like now
  Alpha*Pixmap bar.xpm 23  # adds the second image
  Alpha*Pixmap             # removes the second image
  *Pixmap foo.xpm          # removes the second image as well

png image with alpha channel that is defined in *Pixmap is forced to have
alpha 100. png image that is defined in "Alpha*Pixmap bar.png" gets its
alpha. This seems to be well defined. Correct me if I say a nonsense.

Or maybe just use completely new syntax like:

  Plain, *Gradient         # defines destructive background, like now
  Image [Tiled,Aspect] foo.png   # [Bitmap fg bg] may be a parameter too
  AlphaImage [Tiled,Aspect] bar.png 23
  AlphaImage               # other names: SecondImage, ExtraImage

> (but not by a simple fg ?).

Something tells me that it is not good for colorset to impose presence
or absence of the text shadow. Also shadow may have a thickness parameter.

Maybe it is possible to add text shadow thickness when specifying a font?
And fgsh option of a colorset used when thickness is not 0. I don't think
that sh color is a good default for fgsh, I think it may be computed from
fg by applying shadow function (not from bg), and fg always resets fgsh.

Finally, Olivier, I really like what you do to improve fvwm.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 9 May 2002 06:20:13 +0200

> ParentRelativity becomes set?

Yes, I will fix this. But I've to work on libs/XError.c and some
modules so that the error handlers can deal with XRender errors.
Some modules X core dump with a BadPicture XRender error and this
XRender error should be accepted for some modules as BadPixmap
is accepted.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 10 May 2002 10:57:12 +0200

>   http://www.remote.org/sven/CommonDesktopEnvironment_CDE_.html

Thanks. As I say in an other message I do not think that this should
go into colorest. It seems that this concerns image loading, but maybe
I am wrong.
 
>     foreach $a (1 .. 100) { command("Colorset 1 fg-alpha $a"); }

with just fg:

SendToModule FvwmPerl eval unlock(); \
     foreach $a (1 .. 100) { command("Colorset 1 fg black $a"); }

?

>   AlphaImage               # other names: SecondImage, ExtraImage

Both method seems ok. However, 2 pbs come here. Maybe we should
first think how to implement at the config level colorset in
{Title,Button,Border}Style. Is there a consensus about adding
composed pixmap in colorset?

> or absence of the text shadow. Also shadow may have a thickness parameter.

Yep.
 
> fg by applying shadow function (not from bg), and fg always resets fgsh.

Of course sh is not a good default for fgsh ...
So maybe something like Style * Font "relief int:curent_font_desc".
 
> Finally, Olivier, I really like what you do to improve fvwm.

Thanks, Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 10 May 2002 10:33:32 +0200

> I wouldn't like to have - for example - icon specific colours in

So if I well understand you are opposed to colorset options as:

- IconTint colour percent / IconAlpha percent

which whenever a (mini-)icon is implied in the drawn rectangle
tint this (mini-)icon with "colour" at percent rate "percent"
(apply the mini-icon with an additional alpha of "percent",
respectively).
It seems to me that a fvwm typical drawing is constituted
by a background (bg, *Pixmap, *Gradient), a relief (hi/sh),
a text (fg and maybe fgsh) and a (mini-)icon (or a button).
So having options in colorset for (mini-)icon seems to me
natural. Of course some times there are no (mini-)icon, but
also some times there are no text (window buttons). There are
two alternatives: (i) we do not want these new features (maybe
we may choose only one, say IconTint) (ii) adding new config
commands. I've no clear idea about (i) but I think that the
new feature can be cool under certain situations. (ii) leads
to too many new config cmd IMHO (menu style, button style,
maybe a style for icon, and big number of new cmd for modules).

I vote to add  "IconTint colour percent" (no opinion for
IconAlpha). Maybe this option have to do with the CDE xpms,
but I see the CDE xpms stuff as an image format. So it seems
to me that CDE xpms concerns FvwmPicture loading and not
colorset (?).

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 10 May 2002 12:38:36 +0200

> symbolic image colors, this way images may include 3d elements using

Ok, Xpm support symbolic colors: you give arbitrary name and at
load time you use the XpmColorSymbol structure to define the
colors. An implementation should fix some symbolic names. CDE
use: iconColor1, iconColor2, ..., iconColor8, iconGray1, ...,
iconGray8, topShadowColor, SelectColor, selectColor, Background,
bottomShadowColor.

So what we want is a new config cmd (or some styles??)

SymbolicColors iconColor1 a_color, ..., bottomShadowColor a_color

The major problem here is that this command should be dynamic.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 10 May 2002 12:33:47 +0200

On Fri, May 10, 2002 at 10:33:32AM +0200, Olivier Chapuis wrote:
> ...

But why make a special case if there is a mini icon?  If we need
a tint colour, shouldn't it be applicable to any forground, not
just icons?  I see no reason why, for example, text shouldn't
benefit from tinting.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 10 May 2002 18:42:01 +0000

> The major problem here is that this command should be dynamic.

This is not quite what I had in mind when suggested symbolic colors in
xpm. I only care about our symbolic names in colorset context. So this
symbolic color structure, filled by "Colorset Image" command, is enough:

  "bg", "background"
  "fg", "foreground", "selectColor"?
  "sh", "shadow", "bottomShadowColor"
  "hi", "hilight", "topShadowColor"
  "fgsh"

I didn't even mean that symbolic colors once xpm is loaded are dynamic,
but of course dynamic functionality would be good, i.e. if sh is changed,
the symbolic xpm in that colorset is reloaded.

A possible solution to emulate dynamic CDE (or Java) color schemes is by
adding a new SymbolicColors that manages non colorset context colors:

  SymbolicColors iconColor1 <color>, ..., iconGray8 <color>
  Colorset N fg black, bg $[sc.iconColor1]  # static
  Colorset N fg black, bg sc:iconColor1     # dynamic

and reloading all symbolic xpms in all relevant colorsets when this
command is issued, but again my initial intention was to support only 4
(or 5) colorset colors, not CDE color schemes as Dominik understood. :)

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 10 May 2002 21:36:13 +0000

> > > Yes. In fact it seems that we can just allows a percent after the fg

Any of two solutions is ok for me.

> composed pixmap in colorset?

Yes, it would be nice if someone comment on my suggestion about replacing
all current TitleStyle options with one MainColorset option and all
current ButtonStyle options (except for Vector, MiniIcon and Use*Style)
with one Colorset.

BorderStyle seems a bit different, but it also may accept MainColorset
option. And additionally more colorsets for different border sides.

I don't know how adding colorsets affects a flickering that thanks to
Dominik was removed completely in resized decorations. Also the hard
part is supporting the current syntax, i.e. having duplicated code.

> > > > Another idea. There was a request to add shadow to texts, I
> > > > thought about a fg_shadow color property of colorsets. Can this
> > > > feature be handled by FlocaleDrawString?
> > > 

Nice. You may even do like with xft: Font "shadowsize=2:curent_font_desc".

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 11 May 2002 11:26:52 +0000

> just icons?  I see no reason why, for example, text shouldn't

After some thinking I tend to agree with Olivier, he wants to separate
text tinting/fading from icon tinting/fading. This is what we have now
with disabled menu items, only text color is different, but not icon.
I would like to have a menu with all non-faded menu icons (or mini
application icons in case of WindowList), but text in disabled menu items
should be faded (say, by 50%). Another user may like to fade the disabled
icons too (but maybe by different value than text - 75%).

Another case. We don't know much about actual icons used, but it is safe
to apply tinting/fading to most of images to get one or another effect.
but we don't want this effect to affect text color, because text should
usually be contrast to background to be readable, and icons should not.

So it seems there are cases when tinting/fading of text should not affect
tinting/fading of icons and vice versa. Also, having operation for just
text tinting (as oposite to fading that is nice to have) is not absolutely
essential, because unlike images text has only one color that may be
simply redefined in colorset.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 11 May 2002 09:32:08 +0200

> part is supporting the current syntax, i.e. having duplicated code.

After all Dominik work on decor I think that adding colorsets
will not be so difficult. But this is not my first priority,
it is my second priority (if Dominik do not want to do it).
When, I will be ready to start implementation I will comment
on your suggestions about TitleStyle and al.

> Nice. You may even do like with xft: Font "shadowsize=2:curent_font_desc".

You mean shadowsize=2:* is better than refief 2:* ?

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 11 May 2002 18:38:25 +0200

> just icons?  I see no reason why, for example, text shouldn't

I do not think that tint should be applied to fg, *Gradient and
even the transparent part of the background of a pixmap (i.e., bg).
At the present time Tint tints the transparent part of the background
the cs pixmap for *Pixmap colorset (as TintMask does not) and now
I think this is not a good idea.
The reason is that I do not see the interset to tint a colour,
the user can do that by just changing the color in the Colorset
cmd. For Pixmap and mini-icon the situation is totally different.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 11 May 2002 08:21:17 +0200

>   "hi", "hilight", "topShadowColor"

Ha, ok. So you think that symbolic colors is needed to load
xpms into a given colorset only? I had in mind that xpms can
be used in  all fvwm :o). In fact, I think that the place where
xpms can be the most useful are for window buttons, maybe in this
case the Button colorset may be used? 
More generally, if we have a context colorset it can be used:
E.g. AddToMenu "foo%xyz.xpms" will load xyz.xpms with the menu
colorset?

> the symbolic xpm in that colorset is reloaded.

For xpms into a colorset I do not think this is difficult.

One problem I see here is the fg/fgsh colors. When you apply
text on an picture it is not so good that the picture used the
fg/fgsh colors. So we have only 3 relevant colors bg,sh and hi
and for bitmap only one relevant color bg :o((. Maybe we can add
one "icon" color to a colorset (corresponding to the cde SelectColor),
say iconfg? Dominik an objection?

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 11 May 2002 18:10:01 +0000

> You mean shadowsize=2:* is better than refief 2:* ?

This depends on implementation. We use the name relief to mean 3d frame.
I don't think 3d should be used for the text shadow, after all we don't
have fghi color. I thought that shadowsize=2 is a good addition to size=14
that we already have with xft. But any other intuitive name is ok for me.

BTW, how do you want to implement this? By drawing a font twice using
the +<int>+<int> offset? Or maybe <int> times using the +1+1 offset?
How anti-aliasing is affected if at all?

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 12 May 2002 18:21:25 +0200

> the +<int>+<int> offset? Or maybe <int> times using the +1+1 offset?

I think that drawing twice is the good solution. So 1 and 2
(and maybe 3 for some very bold font) will be usefull.
 
> How anti-aliasing is affected if at all?

It is affected, but in the good way.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 13 May 2002 12:02:13 +0200

On Sat, May 11, 2002 at 08:21:17AM +0200, Olivier Chapuis wrote:
> say iconfg?

I'm more fond of colours that are referenced by their meaning, not
by their context.  Is it really necessary to distinguish between
different kinds of foreground?  After all, if text and a pixmap
are used in the same object, one can define a second colour set
for the pixmap.  Hm, it might be difficult to understand which
colour set is used, for example, for the background colour.

In the long run, I think it's a good idea to put all the visual
effects into colour sets and provide a function
"render_into_area".  With that, the drawing code in the
modules could be simplified a lot.

  typedef struct
  {
    colorset text_colorset;
    /* description of font and string to draw */
    /* ... */
  } render_text_object;

  typedef struct
  {
    colorset picture_colorset;
    /* ... */
  } render_picture_object;

  typedef struct
  {
    render_text_object *text;
    render_picture_object *picture;
  } render_object;

  void render_gui_object_into_area(
    Display *dpy, Drawable dest_d, XRectangle *dest_rect,
    render_object *src_obj);

> Dominik an objection?

Not if we can find a good name that allows to use the additional
parts in a generic way.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 13 May 2002 12:07:20 +0200

> cmd.

But the user does not know the algorithm in fvwm.  Consider this:
You have a button button with text and an icon in FvwmButtons.  It
shall visually indicate if the internet connection is up.  One
might want to do this by tinting the whole button.  You could
simply say

  Colorset 123 tint blue

Very comfortable to use and very flexible.  We might want to
distinguish between a foreground and background tint.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 13 May 2002 14:33:08 +0000

> distinguish between a foreground and background tint.

So, it seems, to make everyone happy, we need TintBgImage, TintFgImage and
TintText instead of the current Tint and TintMask, and proposed IconTint.
So a user chooses what he wants to tint when internet arives:

  Colorset 123 TintBgImage blue 40, TintFgImage green 30

or maybe:

  Colorset 123 TintText white 15, TintFgImage white 30

TintBgImage corrects: Image, *Gradient, bg, sh, hi and "fg contrast".
TingFgImage corrects: AlphaImage and (menu/mini) icons.
TintText corrects: fg and fgsh.

Does this make sense for you, Olivier?

Another addition would be to specify static Tint as parameter to Image,
but I think the dynamic solution above may be used for this static task.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 13 May 2002 16:40:20 +0200

> distinguish between a foreground and background tint.

So we should have fgTint, bgTint (for the bg and the gradients),
PixmapTint (for the non transparent part of the pixmap) and
IconTint for the contextual (mini-)icon.
Pixmaptint and IconTint are really natural with Xrender
--
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: Olivier Chapuis <[email-masked]>
Date: Mon, 13 May 2002 21:56:01 +0200

> Does this make sense for you, Olivier?

I added the Tint option, because XRender give it for free: just create
a depth 24 1x1 pixmap of the given color and a depth 8 1x1 pixmap with
an alpha which correspond to the percentage and use XRenderComposite to
tint the original pixmap. So my idea was to use this magic function
to build an infinite number of pixmap from one and to tint (mini-)icons
to get some "interactive" effects. Now you and Dominik ask to tint
a color ... I am not against this and I am agree that this can be
useful for the users, but then I think that we should do the computation
by hands (of course we can use XRenderComposite for the computation).
So my question is given a color (r,g,b), a color  for tinting
(tr,tg,tb) and a percentage p how we compute the tinted colors
(x,y,z)? I think I can find the formula but if one have it this can
save me some (or maybe a lot of) times. Moreover, this will allows to
reimplement XRenderComposite and provied XRender support for those
which do not have it. However, I cannot warranty any success for
these (in particular this may be dramatically slow).

For the syntax it seems that we need:

BgTint: *Gradient, bg, sh, hi
FgTint: fg, fgsh
PixmapTint: Pixmap (transparent part not tinted)
AlphaPixmapTint: for the future AlphaPixmap
IconTint: for (mini-)icon

but again I am a bit reticent for BgTint and FgTint.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 13 May 2002 21:59:51 +0200

On Mon, May 13, 2002 at 12:02:13PM +0200, Dominik Vogt wrote:
> [BottomToTop]

Really, I've not a more generic name than "iconfg" for this
"foreground" icon colour. The reason is that I see that it will
be good to have a new colour for Bitmap fg and xpms but
I do not see where we can use an other colour at all. Of course,
we can introduce fghi but I think that two colours is enough
for text rendering and this will solve in the strange way
this icon fg pbs.
So I suggest "iconfg" as generic name, but any others idea
and objections are welcome.

> modules could be simplified a lot.

I think that I've begin this work.

>     /* description of font and string to draw */

We already have this one: the FlocaleWinString structure that
I've introduced when I reworte the MB_I18N patch. Text rendering
is now totatlly centralized in the libs. 
 
>     colorset picture_colorset;

If I well understand this is currently splited in two part(?)
The colorset and its set background and relief rectangle functions.
I imagine that the second part is the (mini-)icons, so we have
the FvwmPicture and a small set of new libs functions to render
FvwmPicture (or a set of pixmaps, eg. pixmap, mask and alpha) that
I've introduced when I added XRender support. Unfortunately not all
modules use FvwmPicture (and fvwm icons does not for maybe good
reasons), however we are not so far from (mini-)icons rendering
centralization.

>     Display *dpy, Drawable dest_d, XRectangle *dest_rect,

It is not totally clear for me that we should merge everything
in one structure + one functions. The reason is flexibility.
Anyway you can be sure that I take this direction.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 13 May 2002 22:08:24 +0200

> Pixmaptint and IconTint are really natural with Xrender

Oops, a not finished message. Read my answer to the more recent
Mikhael msg on the same subject.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 14 May 2002 10:37:09 +0200

> Pixmaptint and IconTint are really natural with Xrender

Hm, why not make a whole 'tint colour set':

  Colorset 123 fg blue, bg red, sh orange, hi green
  Colorset 234 tintcolorset 123

That's the most flexible solution and it does not even have to
extend colour sets.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 14 May 2002 10:48:59 +0200

> Anyway you can be sure that I take this direction.

Some day in the future I'd like to centralise the 'button' drawing
code.  Most of the drawing in fvwm and the modules boils down to
drawing 'buttons' with a number of features:

 - background image, colour or gradient
 - text
 - icon
 - positioning of the background/foreground in the button
 - raised, flat or sunken relief
 - padding between relief and foreground
 - transparency
 - tinting
 - alpha rendering
 - ...

With the right structures and functions, all the drawing code can
be placed in fvwm or the library.  What I really like about the
idea is that we could get rid of at least half of the module
configuration commands.  For example, a typical button in
FvwmButtons is specified like this:

  *FvwmButtons(Padding 5, Icon my_kill.xpm, Action Close)

In the future this could be

  GuiButton 123 padding 5, pixmap my_kill.xpm
  *FvwmButtons(GuiButton 123, Action Close)

The same button could be used in window decorations and other
modules.  The modules don't have to know anything about drawing
the button.  The library takes care of drawing.  But this is all
clearly something for 3.0 because it will change the module
syntax dramatically.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 16 May 2002 14:44:53 +0200

> (and maybe 3 for some very bold font) will be usefull.

Oh no. The better method is to draw one time with the fg colors
and draw <int> times with the fgsh color with successive +1+1
offsets. This looks goods if the fgsh colour is well chosen. If
we use GetShadow(fg) to get the fgsh colour, then with some
colors as black the fgsh is really bad (it is ok with white).
Also it seems that the bg have to be taken in account.
Does someone has a "good" algo to compute the fgsh from the
fg colours (and maybe also the bg colour).

Olivier