Subject: Re: Theme schemes

From: Tim Phipps <[email-masked]>
Date: Mon, 12 Apr 1999 16:57:55 +0100

I wrote:
> I think I want to create a new module packet, something like M_NEW_LOOK
> that has the following unsigned longs
> 
> header
>   0xffffffff
>   M_NEW_LOOK
>   packet length
>   timestamp
> body
>   Visual *visual
>   GC xorGC - used for rubber bands
>   Colorset 0 (set by DefaultColors & DefaultFont)
>     struct colorset_info {
>        repaint:1;pixmap:1;pixmap_width:12;pixmap_height:12;
>     } info
>     Pixel/Pixmap (depending on info.pixmap)
>     GC foreground (usable with XDrawString/Text/Line)
>     GC relief
>     GC shadow
>   ColorSet N
>     ....
Well, I've implemented this partially. Things have had to change.  You
can't pass GC's around as they are pointers to Xlib malloc'd
structures.  I've had to pass GContext's instead and use "#define
XLIB_ILLEGAL_ACCESS" in the module code to do some deep down dirty
hacking since Xlib doesn't let you do an
XCreateGC(GContextMask,GContext).  Funny thing is, it does let you do
something very similar with Font's.

The new M_NEW_LOOK packet goes:
header
  0xffffffff
  M_NEW_LOOK
  packet length
  timestamp
body
  XVisualIDFromVIsual(Scr.viz)
  Scr.cmap
  Scr.depth
  XGContextFromGC(Scr.drawGC) - used for rubber bands
  Colorset 0 (set by DefaultColors & DefaultFont) {
    struct colorset_info {
       0; (only does background pixels)
    } info
    Scr.StdColors.back
    XGContextFromGC(Scr.StdGC)
    XGContextFromGC(Scr.StdReliefGC)
    XGContextFromGC(Scr.StdShadowGC)
    Scr.StdFont.font->fid
  }

Also, due to the way config reading is implemented (GetConfigLine() eats
all packets until and M_END_CONFIG is received) I've had to put the
sending of M_NEW_LOOK after the config is sent rather than before.  This
makes it a bit messy to decide whether to use Fvwm's defaults or the
modules.  The only way around this is to create a new (module only) Fvwm
command (Send_Look) that a modules would use before asking for its
configuration.

Also, Also, HilightColor is subverted into the decors so I've only
implemented one color set (set by DefaultColors).  The only way of
getting more color sets I think, is to have a ColorSet command which
would create a list of colorsets that could be used in MenuStyles and
Decor definitions, rather than try to work out what to send as colorset
packets.

Anyway, what do you all think?  Is it worth continuing?

Cheers,
Tim.
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 13 Apr 1999 10:03:21 -0400

> command (Send_Look) that a modules would use before asking for its

Is there a way to send this packet along with the other config info?
I'm thinking of setting M_NEW_LOOK and M_CONFIG_INFO on at the same time?
Is the binary data in the M_NEW_LOOK packet the problem with doing this?

> Anyway, what do you all think?  Is it worth continuing?

The capability is interesting.

Are there    enough  common elements  in the   modules    to make this
worthwhile?

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Wed, 14 Apr 1999 08:07:20 +0100

> Is there a way to send this packet along with the other config info?

It gets sent after the config info if the module has requested
M_NEW_LOOK

> Is the binary data in the M_NEW_LOOK packet the problem with doing this?

It was easier to code with binary but it could be sent as a config line
with a series of numbers.  That would make it possible to send before
the rest of the config.  Sounds like a good idea to me, we could remove
the M_NEW_LOOK packet and have a DefaultGraphics command sent along with
the ImagePath etc.

> Are there enough common elements in the modules to make this

That I don't know. Most of the graphical modules are different ways of
doing a window list.  It might be more interesting for the
M_CONFIGURE_WINDOW packet to pass the window decoration GContexts over
so things like the pager could display in the same color scheme as the
windows by default.  There are a few modules that may benefit from
inheriting fvwm's defaults: FvwmButtons, FvwmIdent(done), FvwmScroll,
FvwmTaskBar, FvwmWharf, FvwmIconBox, FvwmScript and FvwmForm all
have widgets and my fvwm2rc has lots of lines for specifying background,
foreground and font (all set to the same with FvwmM4).

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Wed, 28 Apr 1999 17:46:44 +0100

Hi All,
	FvwmIdent and FvwmScroll are now capable of following the colours
specified by the DefaultColors command in fvwm if you don't specify any
colours in their configurations.

What I'd like to do now is to expand the DefaultColors command to be
able to specify the background as a pixmap/gradient.  I'm no good at
parsing or designing syntax so I'd like some suggestions (preferably in
C).

What I'm thinking of is something like the ButtonStyle syntax:

DefaultColors pink maroon -- (TiledPixmap weird.xpm)

I don't know what the -- is for or why there are parens around stuff,
maybe it shouldn't be there.

Any ideas?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 29 Apr 1999 15:38:13 +0200

> maybe it shouldn't be there.

Yes! Don't use that horrible syntax. It's totally unintuitive, hard
to remember and so on. Using positional parameters with cryptic syntax
should be in the past. Two suggestions:

 - DefaultColors pink pixmap weird.xpm

 - DefaultColors pink maroon
   DefaultBackgroiund pixmap weird.xpm

I'd prefer the second version.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 29 Apr 1999 15:39:50 +0200

> maybe it shouldn't be there.

Oh, I forgot in my previous mail: I was thinking abount putting this
gradient/pixmap stuff in the library. No use to have the same parsing
and drawing code at n different places. If you like to make a shot at
rewriting this, feel free.

Bye

Dominik ^_^