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" 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. A possible solution to emulate dynamic CDE (or Java) color schemes is by adding a new SymbolicColors that manages non colorset context colors: SymbolicColors iconColor1 <color>, ..., iconGray8 <color> Colorset N fg black, bg $[sc.iconColor1] # static Colorset N fg black, bg sc:iconColor1 # dynamic and reloading all symbolic xpms in all relevant colorsets when this command is issued, but again my initial intention was to support only 4 (or 5) colorset colors, not CDE color schemes as Dominik understood. :) 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]
