On Sat, May 11, 2002 at 08:21:17AM +0200, Olivier Chapuis wrote:
> On Fri, May 10, 2002 at 06:42:01PM +0000, Mikhael Goikhman wrote:
> > 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?
I'm more fond of colours that are referenced by their meaning, not
by their context. Is it really necessary to distinguish between
different kinds of foreground? After all, if text and a pixmap
are used in the same object, one can define a second colour set
for the pixmap. Hm, it might be difficult to understand which
colour set is used, for example, for the background colour.
In the long run, I think it's a good idea to put all the visual
effects into colour sets and provide a function
"render_into_area". With that, the drawing code in the
modules could be simplified a lot.
typedef struct
{
colorset text_colorset;
/* description of font and string to draw */
/* ... */
} render_text_object;
typedef struct
{
colorset picture_colorset;
/* ... */
} render_picture_object;
typedef struct
{
render_text_object *text;
render_picture_object *picture;
} render_object;
void render_gui_object_into_area(
Display *dpy, Drawable dest_d, XRectangle *dest_rect,
render_object *src_obj);
> Dominik an objection?
Not if we can find a good name that allows to use the additional
parts in a generic way.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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]
