On Tue, Oct 15, 2002 at 04:54:03PM +1000, Cameron Simpson wrote:
> I spent this morning making my "set the root background" work properly,
> and was looking at fvwm-root. I noticed that the manual doesn't match
> the code. Appended is a patch for the manual (against current CVS)
> to address this lack. The color-limit stuff is a bit vague because I
> didn't read that code in depth.
>
Yes. There are visual/cmap issues here when fvwm do not use the
default visual ... I should complete the doc.
> While on this topic, I'm using Esetroot instead of fvwm-root. Why? Purely
> because it sets the ESETROOT_PMAP_ID pixmap property, and aterms listen
> for that. I notice fvwm-root can _clear_ this property but not set
> it. Is there any special reason for this? Merely that you use a different
> property for this?
>
I do not know. There is no mention of this in the ChangeLog's, maybe
we can found an answer in the mailing list archive.
Anyway, some root programs use _XSETROOT_ID other ESETROOT_PMAP_ID
(together with XA_XROOTPMAP_ID). For example xv free the _XSETROOT_ID
pixmap but do not set it (maybe xv has an option for this). xli free
the _XSETROOT_ID pixmap and set it to a 1x1 black pixmap. Both
xli and xv know nothing about ESETROOT_PMAP_ID. On the other hand,
kdesktop and Nautilus use ESETROOT_PMAP_ID and know nothing about
_XSETROOT_ID.
I think we should do the following with fvwm-root (and FvwmBacker):
- In any case free the resource associated with _XSETROOT_ID and
ESETROOT_PMAP_ID (some checking is needed).
- By default, set the _XSETROOT_ID to a None pixmap. This indicate
a bg change, this is useful for apps which use ParentalRelativity to
produce transparency (as fvwm and its modules). Moreover, we do not
waste memory if the user do not use a program which use the "Esetroot"
method for transparency (at present time, by default, fvwm-root set
_XSETROOT_ID to the root pixmap id and exit in the RetainPermanent mode,
so the root pixmap is in X memory).
- Add one option -retain-pixmap. In this case use ESETROOT_PMAP_ID
(and XA_XROOTPMAP_ID) to give the root pixmap id to the world
and exit in RetainPermanent mode. So aterm will be happy as well
as fvwm and any apps which use the Esetroot method for transparency.
So I think we can remove the -fe option and add this -retain-pixmap
option. What do you think?
It seems that there is an informal spec. for the ESETROOT_PMAP_ID
and XA_XROOTPMAP_ID properties. Here it is (from Owen Talyor):
A program that wants to set the background should:
- Create a persistant pixmap by calling to the server with:
dpy = XOpenDisplay(display_name);
XSetCloseDownDisplay (dpy, RetainPixmap);
pmap = XCreatePixmap (dpy, DefaultRootWindow (dpy), width, height,
DefaultDepthOfScreen (DefaultScreenOfDisplay
(dpy)));
XCloseDisplay (dpy)
- Grab the server
- See if ESETROOT_PMAP_ID is set
- If so, call XKillClient(xdisplay, *(Pixmap*)data_esetroot)
- Change ESETROOT_PMAP_ID and _XROOTPMAP_ID to point to the
new pixmap
- Set the pixmap as the background for the root window
- Ungrab the server
I add that XA_XROOTPMAP_ID is for permanent program (as FvwmBacker,
do not know why FvwmBacker do not use it :o/). It should be never
killed.
Patch welcome for fvwm-root. I will modify FvwmBacker.
> I was thinking of adding this facility (as an option, like -fe, since
> it is otherwise a resource waste). I presume it's a bad bad idea to hand
> the same pixmap to both properties, yes?
Yes, as good program (as fvwm :o) will monitor both _XSETROOT_ID
and XA_XROOTPMAP_ID. So, if you set both properties such apps will
see 2 bg changes.
Regards, 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]
