On Tue, May 07, 2002 at 10:43:08PM +0000, Mikhael Goikhman wrote:
> On 07 May 2002 22:22:13 +0200, Olivier Chapuis wrote:
>
> > 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?
>
> 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.
>
Hum, I do not know this CDE stuff. Can you be more precise?
> 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).
>
I am agree that these bitmap_bg and a bitmap_fg options are not good
ideas. But what is your suggestion?
> > 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.
>
> 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.
> > - Add an Pixmap_alpha option: to put the pixmap in a translucent way
> > on the bg.
>
> 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?
>
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.
> 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.
>
> > - 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).
>
> 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?
>
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
--
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]
