On Sat, Jan 28, 2006 at 05:47:34PM +0100, Viktor Griph wrote: > 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: [snip] > >>>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). [anip] > >>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?
You're right. I was under the impression we were talking about
the code that detects ICCCM2 compliant window managers because of
the sheer size of the window manager list. It looks like nobody
bothers to set the corresponding property in any window manager.
> $ 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.
Actually an error *is* generated, but it is processed by the wrong
error handler (i.e. by FvwmErrorHandler). It's not enough to put
an XSync after XSelect input, there should also be one *before*
XSetErrorHandler to prevent that other errors are mistaken as a
clue that another wm is running. I'll commit a patch.
> 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.
No, not at all. XSetErrorHandler is processed locally in Xlib
without any protocol requests to the X server, so only the kernel
scheduling algorithm has some influence on this.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
