Re: fvwm starts when other window manager is already activeOrganization:
On Thu, 22 Sep 2005, Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian BTS has a record of your input] This was reported by a Debian user. Recent versions of fvwm, while being able to detect other versions of fvwm currently running: -- __ fvwm [FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running, try -replace -- are unable to detect other window managers.(Tested with ratpoison and woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm, making this almost every other window manager other than fvwm itself). Older versions of fvwm used to display this warning: -- [FVWM][CatchRedirectError]: ERROR another WM is running -- But the newer ones do not, for reasons I could not debug. This is a regression, and the other window managers are able to detect fvwm and refuse to run. Please see http://bugs.debian.org/328621 for details. manoj I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. /Viktor
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, 28 Jan 2006, Bernhard R. Link wrote: * Viktor Griph [EMAIL PROTECTED] [060128 14:36]: I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. I'm seeing the bug here with the Debian sarge version of XFree86 namely 4.3.0.dfsg.1-14sarge1. I do not know if it contain any patches taken from Xorg, though. Hochachtungsvoll, Bernhard R. Link Well, I really don't know about that. thinking about it the only x-server I'm certain it has worked with is a version of Xsun on solaris 2.8. Looking at the fvwm code I believe it might be that an XSync has been changed to an XFlush in the startup code before changing the errorhandler from the one that traps running WMs to the normal fvwm error handler. But since I'm not sure exactly how this WM-trapping is supposed to work I leave to someone else to decide if changing it back to XSync is correct. /Viktor
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, Jan 28, 2006 at 02:20:13PM +0100, Viktor Griph wrote: On Thu, 22 Sep 2005, Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian BTS has a record of your input] This was reported by a Debian user. Recent versions of fvwm, while being able to detect other versions of fvwm currently running: -- __ fvwm [FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running, try -replace -- are unable to detect other window managers.(Tested with ratpoison and woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm, making this almost every other window manager other than fvwm itself). Older versions of fvwm used to display this warning: -- [FVWM][CatchRedirectError]: ERROR another WM is running -- But the newer ones do not, for reasons I could not debug. This is a regression, and the other window managers are able to detect fvwm and refuse to run. Please see http://bugs.debian.org/328621 for details. manoj I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. No, the only change since at least 2.3.0 was introducing the -replace option. We haven't touched this code in *ages*. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, 28 Jan 2006, Dominik Vogt wrote: On Sat, Jan 28, 2006 at 02:20:13PM +0100, Viktor Griph wrote: On Thu, 22 Sep 2005, Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian BTS has a record of your input] This was reported by a Debian user. Recent versions of fvwm, while being able to detect other versions of fvwm currently running: -- __ fvwm [FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running, try -replace -- are unable to detect other window managers.(Tested with ratpoison and woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm, making this almost every other window manager other than fvwm itself). Older versions of fvwm used to display this warning: -- [FVWM][CatchRedirectError]: ERROR another WM is running -- But the newer ones do not, for reasons I could not debug. This is a regression, and the other window managers are able to detect fvwm and refuse to run. Please see http://bugs.debian.org/328621 for details. manoj I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. No, the only change since at least 2.3.0 was introducing the -replace option. We haven't touched this code in *ages*. Have you not? $ cvs log -r1.290 -N fvwm.c revision 1.290 date: 2002/03/17 17:34:15; author: domivogt; state: Exp; lines: +7 -10 * Replaced Xsync with XFlush almost everywhere. Note: it's rarely necessary to use XSync. XFlush usually suffices and is faster. * More work on frame layout. * Some general clean up. The relevant part of the cvs diff -r 1.289 -r 1.290 fvwm.c: Index: fvwm.c === RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v retrieving revision 1.289 retrieving revision 1.290 diff -u -r1.289 -r1.290 --- fvwm.c 15 Mar 2002 17:02:25 - 1.289 +++ fvwm.c 17 Mar 2002 17:34:15 - 1.290 @@ -557,21 +559,21 @@ CWEventMask | CWOverrideRedirect | CWColormap | CWBackPixmap | CWBorderPixel, attributes); XMapWindow(dpy, Scr.NoFocusWin); - SetMWM_INFO(Scr.NoFocusWin); FOCUS_SET(Scr.NoFocusWin); - XSync(dpy, 0); + frame_init(); + XFlush(dpy); if(debugging) { sync_server(1); } - SetupICCCM2 (replace_wm); + SetupICCCM2(replace_wm); XSetErrorHandler(CatchRedirectError); XSetIOErrorHandler(CatchFatal); XSelectInput(dpy, Scr.Root, XEVMASK_ROOTW); - XSync(dpy, 0); + XFlush(dpy); XSetErrorHandler(FvwmErrorHandler); I think that last XSync really should be there since, if I understand the test correctly it relies on an error to be generated if a window manager already exists, and XSync does wait until all requests are processed, and the errors handled, but XFlush just flushes the output buffer. I guess it's up to the threadin model of the X-server weather or not any errors generated by recently flushed requests are handled before or after the request to change error handler to FvwmErrorHandler is processed. /Viktor
CVS griph: fix detection of non-ICCCM2 WMs (bug 3151)
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/01/28 11:01:09 Modified files: . : NEWS ChangeLog fvwm : fvwm.c Log message: fix detection of non-ICCCM2 WMs (bug 3151)
Re: fvwm starts when other window manager is already activeOrganization: Manoj Srivastava's Home
* Viktor Griph [EMAIL PROTECTED] [060128 16:48]: Well, I really don't know about that. thinking about it the only x-server I'm certain it has worked with is a version of Xsun on solaris 2.8. Looking at the fvwm code I believe it might be that an XSync has been changed to an XFlush in the startup code before changing the errorhandler from the one that traps running WMs to the normal fvwm error handler. But since I'm not sure exactly how this WM-trapping is supposed to work I leave to someone else to decide if changing it back to XSync is correct. I really think that is the problem (XSync vs XFlush). Looking into the libX11 code XFlush only writes all pending things to the X-server. Unless writing more would block[1] it does not read anything. Thus it cannot receive any Error notification from the server thus CatchRedirectError is never called. When I replace the XFlush with an XSync, the message from the CatchRedirectError handler is shown and fvwm termiantes correctly if any other window manager is running. Changing XSync back to XFlush and adding some diagnostics to FvwmErrorHandler I see it receiving a BadAccess(10) Error for a X_ChangeWindowAttributes(2) request. And XSelectInput simply sends a ChangeWindowAttributes request for the specified window and EXEVMASK_ROOTW contains SubstructureRedirectMask (which fits to the name of the CatchRedirectError handler) and xspec/proto.txt tells: | Multiple clients can select input on the same window; their | event-masks are disjoint. When an event is generated, it | will be reported to all interested clients. However, only | one client at a time can select for SubstructureRedirect, | only one client at a time can select for ResizeRedirect, and | only one client at a time can select for ButtonPress. An | attempt to violate these restrictions results in an Access | error. Hochachtungsvoll, Bernhard R. Link [1] This could be the cause of it working earlier or under different operating systems, the buffers for unix sockets or tcp connections might have increased.
Re: fvwm starts when other window manager is already activeOrganization: Manoj Srivastava's Home
* Viktor Griph [EMAIL PROTECTED] [060128 14:36]: I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. I'm seeing the bug here with the Debian sarge version of XFree86 namely 4.3.0.dfsg.1-14sarge1. I do not know if it contain any patches taken from Xorg, though. Hochachtungsvoll, Bernhard R. Link
FvwmIconBox Png Format
FvwmIconBox seems to not support png files. I've tried many different ways, and, whatever the reason is, it always falls back to the standard window icon. I've tried setting the Icon on Style, but then the icon on FvwmIconBox is omitted. When set from FvwmIconBox itself the icon isnt loaded (standard takes place). I may have done smth wrong, but i believe this is a bug. thx BodyDrop