On Fri, May 10, 2002 at 06:42:01PM +0000, Mikhael Goikhman wrote: > On 10 May 2002 12:38:36 +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: > > > > > > > > > > > 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. > > > > Ok, Xpm support symbolic colors: you give arbitrary name and at > > load time you use the XpmColorSymbol structure to define the > > colors. An implementation should fix some symbolic names. CDE > > use: iconColor1, iconColor2, ..., iconColor8, iconGray1, ..., > > iconGray8, topShadowColor, SelectColor, selectColor, Background, > > bottomShadowColor. > > > > So what we want is a new config cmd (or some styles??) > > > > SymbolicColors iconColor1 a_color, ..., bottomShadowColor a_color > > > > The major problem here is that this command should be dynamic. > > This is not quite what I had in mind when suggested symbolic colors in > xpm. I only care about our symbolic names in colorset context. So this > symbolic color structure, filled by "Colorset Image" command, is enough: > > "bg", "background" > "fg", "foreground", "selectColor"? > "sh", "shadow", "bottomShadowColor" > "hi", "hilight", "topShadowColor" > "fgsh" >
Ha, ok. So you think that symbolic colors is needed to load xpms into a given colorset only? I had in mind that xpms can be used in all fvwm :o). In fact, I think that the place where xpms can be the most useful are for window buttons, maybe in this case the Button colorset may be used? More generally, if we have a context colorset it can be used: E.g. AddToMenu "foo%xyz.xpms" will load xyz.xpms with the menu colorset? > I didn't even mean that symbolic colors once xpm is loaded are dynamic, > but of course dynamic functionality would be good, i.e. if sh is changed, > the symbolic xpm in that colorset is reloaded. > For xpms into a colorset I do not think this is difficult. One problem I see here is the fg/fgsh colors. When you apply text on an picture it is not so good that the picture used the fg/fgsh colors. So we have only 3 relevant colors bg,sh and hi and for bitmap only one relevant color bg :o((. Maybe we can add one "icon" color to a colorset (corresponding to the cde SelectColor), say iconfg? Dominik an objection? 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]
