On Tue, Jul 09, 2002 at 08:18:33AM +0200, Olivier Chapuis wrote:
> 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.
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).
> 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?
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 PROTECTED], 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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
