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 -0000 1.289
+++ fvwm.c 17 Mar 2002 17:34:15 -0000 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
