On 08 May 2002 07:28:29 +0200, Olivier Chapuis wrote: > > 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 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 > > 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? Maybe "*Bitmap xbm fg bg" option similar to *Pixmap? > > > 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. 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"); } :-) > > > - 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. 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 > > 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 ?). 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. -- 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]
