On Fri, May 10, 2002 at 09:36:13PM +0000, Mikhael Goikhman wrote:
> On 10 May 2002 10:57:12 +0200, Olivier Chapuis wrote:
> > 
> > On Wed, May 08, 2002 at 10:48:39PM +0000, Mikhael Goikhman wrote:
> > > 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:

> 
> > > 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
> > 
> > Both method seems ok. However, 2 pbs come here. Maybe we should
> > first think how to implement at the config level colorset in
> > {Title,Button,Border}Style. Is there a consensus about adding
> > composed pixmap in colorset?
> 
> Yes, it would be nice if someone comment on my suggestion about replacing
> all current TitleStyle options with one MainColorset option and all
> current ButtonStyle options (except for Vector, MiniIcon and Use*Style)
> with one Colorset.
> 
> BorderStyle seems a bit different, but it also may accept MainColorset
> option. And additionally more colorsets for different border sides.
> 
> I don't know how adding colorsets affects a flickering that thanks to
> Dominik was removed completely in resized decorations. Also the hard
> part is supporting the current syntax, i.e. having duplicated code.
>

After all Dominik work on decor I think that adding colorsets
will not be so difficult. But this is not my first priority,
it is my second priority (if Dominik do not want to do it).
When, I will be ready to start implementation I will comment
on your suggestions about TitleStyle and al.

> > > > > 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.
> > 
> > Yep.
> >  
> > > 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.
> > 
> > Of course sh is not a good default for fgsh ...
> > So maybe something like Style * Font "relief int:curent_font_desc".
> 
> Nice. You may even do like with xft: Font "shadowsize=2:curent_font_desc".
>

You mean shadowsize=2:* is better than refief 2:* ?

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