Subject: Re: Colorset ideas

From: Olivier Chapuis <[email-masked]>
Date: Tue, 9 Jul 2002 08:18:33 +0200

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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Jul 2002 15:40:06 +0200

> and  EffectSetAndUpdate I will implement tinting this way.

I still think it's not a good idea to overload colour sets with
too many parameters.  The solution you propose (and I think it's
the one I had originally in mind) has one major flaw:  If the
EffectSet is a subordinate part of a colour set, you still have to
define different colour sets for each effect:  Let's assume there
are two buttons that share the same colours, but different
effects.  You need

  Button A
    - colour set A
       - effect set A

  Button B
    - colour set B
       - effect set B

But colour sets A and B are identical (except for the effect set
pointer).  It would be better to separate them:

           Button A
  colour set A - effect set A
  ...

(BTW, I wouldn't call it EffectSet - it suggests it's a set of
items of similar types.  But it's actually just a definition of
one (complex) effect.)

Eventually, I'd like to have a structure that defines "GUI
objects" as a combination of

  - colours to draw various parts
  - the object to draw in the foreground (e.g. text or a picture)
  - the object to draw in the background
  - a relief definition
  - position information of the previous three objects
  - effect definitions

How about this hierarchy of objects:

  gui_object
  - relief_object
    - size and position
    - raised/sunk/flat/...
    - fill pattern
  - fore_object
    - size and position
    - text
      - font
    - graphics
    - effects
  - back_object
    see above
  - colours

Our current colour set would be promoted to gui objects with the
colour and grpahics definitions moved into subordinate structures.
For example,

  Colorset 1 fg red, bg green, Pixmap foo.xpm

would become:

  NewColorSet 1 fg red, bg green
  GfxObject 1 Pixmap foo.xpm
  GuiObject BackGfxObject 1, NewColorSet 1

In addition, this can be used to not just define module
backgorounds, but individual elements of the graphics.  Here's a
hypothetical config for FvwmButtons:

  # general button drawing colours
  NewColorSet 1 fg black, bg gray
  # module background
  GfxObject 1 BGradient 128 blue red
  # button background
  GfxObject 2 ParentRelative
  # button foregrounds
  GfxEffects 1 Tint red, Tintpct 50
  GfxObject 3 Pixmap move.xpm, Effects 1
  GfxObject 4 Pixmap resize.xpm, Text "bla", \
    Font lucidasanstypewriter-12, TextBelowIcon
  # GUI objects
  GuiObject 1 NewColorSet 1, BackGfxObject 1
  GuiObject 1 NewColorSet 1, BackGfxObject 2, ForeGfxObject 3
  GuiObject 1 NewColorSet 1, BackGfxObject 2, ForeGfxObject 4
  
etc.  I don't suggest implementing something like this now, but
whatever we do now, it should not require to rewrite the syntax
completely if we ever move to the "GuiObject" approach.

Hm, just think of the possibilities:  90% of the module drawing
code moved into a single library; the looks of all module elements
(buttons, reliefs, background, shape, etc. configurable at run
time with only the code to call the library routines when anything
changes); module configuration lines reduce to

  *FvwmPager: MainGuiObject 1
  *FvwmPager: WindowGuiObject 2
  *FvwmPager: HilightGuiObject 3
  *FvwmIconMan: MainGuiObject 1
  *FvwmButtons: MainGuiObject 1
  *FvwmButtons: (GuiObject 101)
  *FvwmButtons: (GuiObject 102)
  ...

replacing dozens of individual module options.

(I'm aware that the above is vastly inconsistent and won't work
out of the box).

> syntax (even with back compatibility).

To summarize the abouve:  yes.  Do whatever you think is best, but
try to encapsulate the functionality as good as possible so that
it may be taken out en-bloc one day.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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: Mikhael Goikhman <[email-masked]>
Date: Wed, 10 Jul 2002 13:46:22 +0000

> def + update all the colorset which use the tint set).

I think an effect (tint, alpha) should be only a filter, that only affects
(until disabled) the corresponding properties, and does not change them.
In the future we may add something like DissolveEffect that transfers an
effect to a colorset permanently, but this is not important for now.

But I don't think Effectset is really needed,

> and  EffectSetAndUpdate I will implement tinting this way.

Agree, so Effectset may be emulated using a function.

  AddToFunc ApplyColorsetEffect
  + I Colorset $0 fgTint blue 30, bgTint red 50, IconTint black 10, ...

  AddToFunc ResetColorsetEffect
  + I Colorset $0 *Tint, *Alpha

The last 2 special names with asterisk are shortcuts, they may be used to
set the same tint or alpha effect parameters to all relevant properties,
or to reset them.

I think that properties <property>Tint and <property>Alpha should be reset
automatically when <property> is changed, either directly or inderectly.

I am not sure what hiTint and shTint are good for. They should use bgTing.

> syntax (even with back compatibility).

We already changed the colorset syntax by removing FvwmTheme.
I suggest to use the word Image for the same reason that we once renamed
PixmapPath to ImagePath, now fvwm even supports xbm and png, not just xpm.

I think you agree that 3 existing properties (TiledPixmap, AspectPixmap
and Pixmap) are not really 3 but 1, every one disables an other.
And you suggest to have one PixmapAlpha, not separate alphas for all 3.
So instead of duplicating these properties to ExtraPixmap and having 6,
I suggest to have only 2 properties:

  Image and SecondImage (or ExtraImage)

And accordingly:

  ImageAlpha and SecondImageAlpha

> So, may I go?

I would say, yes, after we come to an agreement about names. :)

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Jul 2002 16:08:33 +0200

> PixmapPath to ImagePath, now fvwm even supports xbm and png, not just xpm.

PixmapPath was *not* renamed to ImagePath.  The reason for the new
name was to merge the two separate paths (IconPath and PixmapPath)
into a single one.

Pixmap is the name of the internal X picture object, not the name
of the image file format.  Whatever the image is loaded from, X
still uses Pixmaps internally.  I see no naming conflict here. 

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 10 Jul 2002 14:34:15 +0000

> name was to merge the two separate paths (IconPath and PixmapPath)

I know, a proposed PicturePath was renamed to ImagePath.

> still uses Pixmaps internally.  I see no naming conflict here. 

This option requires a file (in one or another image format, that is
searched in ImagePath) and should be named accourdingly IMHO.

Strictly speaking an xbm bitmap is not pixmap, it requires 2 colors as
parameters to be a pixmap.

Png image is not strictly speaking a pixmap as well, it contains more
information like alpha blending that is actually used in colorsets.

These are my reasons to rename "Pixmap file" to "Image file" in colorsets.

Regards,
Mikhael.