Re: PATCH: bin/fvwm-root.1: missing option documentation ...
On Wed, Oct 16, 2002 at 09:21:46AM +1000, Cameron Simpson wrote: On 13:00 15 Oct 2002, Dominik Vogt fvwm-workers@fvwm.org wrote: | On Tue, Oct 15, 2002 at 08:34:57PM +1000, Cameron Simpson wrote: | On 11:02 15 Oct 2002, Dominik Vogt fvwm-workers@fvwm.org wrote: | | Can you please re-post the complete patch, preferrably as an | | attachment? | Sure. Attached below. | Applied. Thanks. Anyone with any comments of the set the Esetroot X11 property option? Should I bother? But I've answer this question and more (To: you and the fvwm-workers list). Maybe this mail never arrive (can one see this mail in the workers list?). Anyway, here it is again: 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]
Re: PATCH: bin/fvwm-root.1: missing option documentation ...
On 07:21 16 Oct 2002, Olivier Chapuis [EMAIL PROTECTED] wrote: | Anyone with any comments of the set the Esetroot X11 property option? | Should I bother? | | But I've answer this question and more (To: you and the fvwm-workers | list). Maybe this mail never arrive (can one see this mail in the | workers list?). Race conditions - found your reply after posting the above :-( Thanks. Will read and then code. Cheers, -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ Because of its special customs, crossposting between alt.peeves and normal newsgroups is discouraged. - Cameron Spitzer -- 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]
PATCH: bin/fvwm-root.1: missing option documentation ...
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. 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 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? -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ --- fvwm-root.1.origTue Oct 15 10:13:10 2002 +++ fvwm-root.1 Tue Oct 15 10:19:27 2002 @@ -10,6 +10,8 @@ .B fvwm-root .RB [ \-d ] .RB [ \-fe ] +.RB [ \-dither ] +.RB [ \-no-dither ] .I image_file .SH DESCRIPTION @@ -33,6 +35,21 @@ Causes fvwm-root to free the memory associated with the ESETROOT_PMAP_ID property. This is useful if you alternately use fvwm-root and an Esetroot compatible program. +.TP +.BI -dither +Causes fvwm-root to dither images for smoother rendition on displays +with color depth of 16 or lower. +.TP +.BI -no-dither +Causes fvwm-root NOT to dither images. +.TP +.BI -color-limit ncolors +Causes fvwm-root to limit its color use to +.I ncolors +(if specified). +.TP +.BI -no-color-limit +Causes fvwm-root NOT to limit its color use. .SH COMPATIBILITY In the past this utility was called -- 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]
Re: PATCH: bin/fvwm-root.1: missing option documentation ...
On 16:54 15 Oct 2002, IPM Return requested [EMAIL PROTECTED] 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. [...] | .RB [ \-fe ] | +.RB [ \-dither ] | +.RB [ \-no-dither ] | .I image_file I must be low on blood sugar. Of course, please also add: +.RB [ \-color-limit [ \fIncolors\fP ] ] +.RB [ \-no-color-limit ] to the SYNOPSIS. Doh. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ What's the point of having Nebraska if we can't put it to its highest and best use? - Patrick Bedard arguing for a 100 mph speed limit -- 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]
Re: PATCH: bin/fvwm-root.1: missing option documentation ...
On Tue, Oct 15, 2002 at 05:10:06PM +1000, Cameron Simpson wrote: On 16:54 15 Oct 2002, IPM Return requested [EMAIL PROTECTED] 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. [...] | .RB [ \-fe ] | +.RB [ \-dither ] | +.RB [ \-no-dither ] | .I image_file I must be low on blood sugar. Of course, please also add: +.RB [ \-color-limit [ \fIncolors\fP ] ] +.RB [ \-no-color-limit ] to the SYNOPSIS. Doh. Can you please re-post the complete patch, preferrably as an attachment? Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- 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]
Re: PATCH: bin/fvwm-root.1: missing option documentation ...
On 11:02 15 Oct 2002, Dominik Vogt fvwm-workers@fvwm.org wrote: | Can you please re-post the complete patch, preferrably as an | attachment? Sure. Attached below. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt.- Blair P. Houghton --- bin/fvwm-root.1.origTue Oct 15 10:13:10 2002 +++ bin/fvwm-root.1 Tue Oct 15 20:31:07 2002 @@ -10,6 +10,11 @@ .B fvwm-root .RB [ \-d ] .RB [ \-fe ] +.RB [ \-dither ] +.RB [ \-no-dither ] +.RB [ \-color-limit +.RI [ ncolors ] ] +.RB [ \-no-color-limit ] .I image_file .SH DESCRIPTION @@ -33,6 +38,21 @@ Causes fvwm-root to free the memory associated with the ESETROOT_PMAP_ID property. This is useful if you alternately use fvwm-root and an Esetroot compatible program. +.TP +.BI -dither +Causes fvwm-root to dither images for smoother rendition on displays +with color depth of 16 or lower. +.TP +.BI -no-dither +Causes fvwm-root NOT to dither images. +.TP +.BI -color-limit ncolors +Causes fvwm-root to limit its color use to +.I ncolors +(if specified). +.TP +.BI -no-color-limit +Causes fvwm-root NOT to limit its color use. .SH COMPATIBILITY In the past this utility was called
Re: PATCH: bin/fvwm-root.1: missing option documentation ...
On Tue, Oct 15, 2002 at 08:34:57PM +1000, Cameron Simpson wrote: On 11:02 15 Oct 2002, Dominik Vogt fvwm-workers@fvwm.org wrote: | Can you please re-post the complete patch, preferrably as an | attachment? Sure. Attached below. Applied. Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- 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]
Re: PATCH: bin/fvwm-root.1: missing option documentation ...
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]
Re: PATCH: bin/fvwm-root.1: missing option documentation ...
On 13:00 15 Oct 2002, Dominik Vogt fvwm-workers@fvwm.org wrote: | On Tue, Oct 15, 2002 at 08:34:57PM +1000, Cameron Simpson wrote: | On 11:02 15 Oct 2002, Dominik Vogt fvwm-workers@fvwm.org wrote: | | Can you please re-post the complete patch, preferrably as an | | attachment? | Sure. Attached below. | Applied. Thanks. Anyone with any comments of the set the Esetroot X11 property option? Should I bother? -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ ERROR 155 - You can't do that. - Data General S200 Fortran error code list -- 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]
