On Tue, May 14, 2002 at 10:37:09AM +0200, Dominik Vogt wrote:
> On Mon, May 13, 2002 at 04:40:20PM +0200, Olivier Chapuis wrote:
> > On Mon, May 13, 2002 at 12:07:20PM +0200, Dominik Vogt wrote:
> > > On Sat, May 11, 2002 at 06:38:25PM +0200, Olivier Chapuis wrote:
> > > > On Fri, May 10, 2002 at 12:33:47PM +0200, Dominik Vogt 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.
> > > > >
> > > > 
> > > > 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.
> > > 
> > > 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.
> > >
> > 
> > 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
> 
> Hm, why not make a whole 'tint colour set':
> 
>   Colorset 123 fg blue, bg red, sh orange, hi green
>   Colorset 234 tintcolorset 123
> 

This does not work as you should specify the % of the tinting
and it is natural to have different  tinting % for fg, bg, ...etc.
We can add a new cmd

EffectSet 123 fg blue 30, bg red 50, PixmapTint black 10, IconTint black 10, \
        fg_text 80

The advantage is that one EffectSet can be used for multiple colorset. The
disadvantage come from updating problems: at "startup" there is no pbs,
you define EffectSet 123 and after colorset 234 which use Effect 123 when
the main colorset pixmap is created. But now if you want to change
the pixmap of the colorset 234 and its tint you should do

Effectset 123 PixmapTint white 10 # -> we should update the main pixmap of
                                     colorset 123 (and maybe others) and
                                     send it to the modules
Colorset 234 Pixmap New.xpm     # -> update and send again ...

So it seems we should have two "EffectSet" command: EffectSet (just the
definition of the tints and alpha's) and EffectSetAndUpdate (tint/alpha
def + update all the colorset which use the tint set).
IMHO, I think that just having bgTint, fgTint, shTint, hiTint,
PixmapTint and IconTint _into_ the Colorset command is a simple
and good solution. So if there is no "strong" vote for EffectSet
and  EffectSetAndUpdate I will implement tinting this way.

In addition of tint I would like to implement user defined alpha-blending
and Add*Pixmap. We already have fg_alpha (maybe this should be fgAlpha),
and I would like to have:

  PixmapAlpha percent # apply the pixmap with a fading effect
                      # determined by percent
  IconAlpha   percent # the same thing for the contextual (mini-)icon

Finally I think it will be good to be able to add _one_ pixmap:

Extra{,Tiled,Aspect}Pixmap image_file

(together with ExtraPixmapTint and ExtraPixmapAlpha)

Mikhael suggests to use Alpha*Pixmap in the place of Extra*Pixmap,
but I think that "Alpha" will be confusing. Also Mikhael
suggests to use an other syntax by using "Image" in the place
of "Pixmap" everywhere. I am not sure we should change the
syntax (even with back compatibility).

So, may I go?

Olivier


--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]

Reply via email to