Subject: Theme schemes

From: Tim Phipps <[email-masked]>
Date: Fri, 26 Feb 1999 17:19:34 +0000

Just some thought re: making it easier to add themes/Gnome/KDE/CDE
support.

What if fvwm were to send a list of graphics contexts to modules to use
a defaults together with a refresh command (not xrefresh) whenever any
of them change?

What I mean is:
1) change fvwm so it keeps the same CG's instead of destroying/creating
them whenever a colour changes

2) send a list of CG's when a module starts

3) the modules to use these GC's by default

4) a module message - refresh - to get a redraw, can't rely on xrefresh
as backing store may be in effect

The GC's I am thinking of are:
Foreground suitable for XDrawString
Background suitable for XFillRectangle (maybe XSetBackground)
Relief suitable for XDrawLine
Shadow ditto

FocusForeground, FocusBackground, FocusRelief, FocusShadow for the
current window
NormalForeground, NormalBackground, NormalRelief, NormalShadow for
others
IconForeground, IconBackground, IconRelief, IconShadow for icons

Is it possible to share GC's like this? It would mean changing all the
modules to not create their own, but it would mean that by default all
the modules have the same colour scheme as fvwm and changing themes
would only require fvwm to modify the GC's and then broadcast a refresh.
Ideaaly I'd like the backgroundGC's to be able to be a pixmap rather
than just a colour.

Any thoughts?

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: Brad Giaccio <[email-masked]>
Date: Fri, 26 Feb 1999 12:27:51 -0500

> Ideaaly I'd like the backgroundGC's to be able to be a pixmap rather

It is the right line of thinking but we can't share graphic contexts or any other structure because the modules are in a seperate process space, we would basically need to pass via pipes the updates to the graphic contexts.  That is, if you chnage the background to blue, all running modules would get a messge Background=blue then they could reset their background values and repaint.

This type of code of course screams to be put in a generic module library along with all the parsing and possibly the error handlers.

Brad

---

From: Matthias Clasen <[email-masked]>
Date: Sat, 27 Feb 1999 21:05:36 +0100

> Ideaaly I'd like the backgroundGC's to be able to be a pixmap rather

I'm fairly sure that it is not possible to share X abstractions
across different connections, since the server allocates disjunct
ranges of 32-bit values to use for abstractions for every connection
(this is so that creating abstractions doesn't need a round-trip)

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Matthias Clasen <[email-masked]>
Date: Sun, 28 Feb 1999 14:15:35 +0100

Sorry, I answered too quickly...
I was wrong, it is in fact possible to use abstractions
created via other connections. To cite the X Protocol
Reference Manual:

X does not provide any protection from unauthorized access
to individual windows, pixmaps or other abstactions, once
a connection has been made. For example, if an application
gets (or guesses) the abstract ID of a window it did not
create, using the QueryTree request, it can manipulate or
even destroy the window. This property was necessary so that
window managers could be written independently of the window
system. It is a matter of courtesy that applications other
than window managers do not attempt this sort of antisocial
behavior.

The only caveat is that the lifetime of an abstaction is
determined by the lifetime of the connection it was created
by (unless SetCloseDownMode is used). But this should not
be a problem in the case of fvwm and its modules.

Matthias