On Mon, May 13, 2002 at 09:59:51PM +0200, Olivier Chapuis wrote:
> 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.
Some day in the future I'd like to centralise the 'button' drawing
code. Most of the drawing in fvwm and the modules boils down to
drawing 'buttons' with a number of features:
- background image, colour or gradient
- text
- icon
- positioning of the background/foreground in the button
- raised, flat or sunken relief
- padding between relief and foreground
- transparency
- tinting
- alpha rendering
- ...
With the right structures and functions, all the drawing code can
be placed in fvwm or the library. What I really like about the
idea is that we could get rid of at least half of the module
configuration commands. For example, a typical button in
FvwmButtons is specified like this:
*FvwmButtons(Padding 5, Icon my_kill.xpm, Action Close)
In the future this could be
GuiButton 123 padding 5, pixmap my_kill.xpm
*FvwmButtons(GuiButton 123, Action Close)
The same button could be used in window decorations and other
modules. The modules don't have to know anything about drawing
the button. The library takes care of drawing. But this is all
clearly something for 3.0 because it will change the module
syntax dramatically.
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]
