On Mon, May 13, 2002 at 12:02:13PM +0200, Dominik Vogt wrote:
> 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?
> > Dominik an objection?
>
> 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.
>
> [BottomToTop]
>
> Not if we can find a good name that allows to use the additional
> parts in a generic way.
>
Really, I've not a more generic name than "iconfg" for this
"foreground" icon colour. The reason is that I see that it will
be good to have a new colour for Bitmap fg and xpms but
I do not see where we can use an other colour at all. Of course,
we can introduce fghi but I think that two colours is enough
for text rendering and this will solve in the strange way
this icon fg pbs.
So I suggest "iconfg" as generic name, but any others idea
and objections are welcome.
>
> 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.
>
I think that I've begin this work.
> typedef struct
> {
> colorset text_colorset;
> /* description of font and string to draw */
> /* ... */
> } render_text_object;
>
We already have this one: the FlocaleWinString structure that
I've introduced when I reworte the MB_I18N patch. Text rendering
is now totatlly centralized in the libs.
> typedef struct
> {
> colorset picture_colorset;
> /* ... */
> } render_picture_object;
>
If I well understand this is currently splited in two part(?)
The colorset and its set background and relief rectangle functions.
I imagine that the second part is the (mini-)icons, so we have
the FvwmPicture and a small set of new libs functions to render
FvwmPicture (or a set of pixmaps, eg. pixmap, mask and alpha) that
I've introduced when I added XRender support. Unfortunately not all
modules use FvwmPicture (and fvwm icons does not for maybe good
reasons), however we are not so far from (mini-)icons rendering
centralization.
> 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);
>
It is not totally clear for me that we should merge everything
in one structure + one functions. The reason is flexibility.
Anyway you can be sure that I take this direction.
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]
