On Tue, Aug 29, 2006 at 10:18:30PM +0200, Viktor Griph wrote: > On Tue, 29 Aug 2006, Viktor Griph wrote: > > >On Tue, 29 Aug 2006, Dominik Vogt wrote: > > > >>On Mon, Aug 28, 2006 at 08:07:31PM +0200, Viktor Griph wrote: > >>>On Mon, 28 Aug 2006, Andreas Ehliar wrote: > >>> > >>>>I have a problem with fpga_editor as reported in bug 4062. With some > >>>>help from #fvwm I managed to find something suspicious. fpga_editor > >>>>does an UnmapWindow request and a MapWindow request right after each > >>>>other. > >>>> > >>>>An example program that does the same is located at > >>>>http://www.da.isy.liu.se/~ehliar/priv/map_unmap.c . > >>>> > >>>>The example program will show a window for 1 second and it will then > >>>>disappear if running under fvwm. > >>>> > >>>>The bug seems very similar to the bug reported in this thread: > >>>>http://www.mail-archive.com/fvwm@hpc.uh.edu/msg08195.html > >>>> > >>>> > >>> > >>>This bug is related to the handling of MapRequests in fvwm. (See > >>>http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15491.html.) > >>>I know of three different ways to address it, but don't know if there is > >>>any downside to them. > >> > >>>The different approches are > >>>1) Change AddWindow to look at the trigger event for the mapped window if > >>>the window in the execution context is gone. I think this is too late in > >>>the line to address this. > >> > >>>2) Change the Handling of MapRequest to call AddWindow with the window > >>>being mapped in the execution context. (I think this is better than 1) > >> > >>I don't actually understand the problem or the suggested > >>solutions. Can you explain it a bit? > >> > > > >The problem is that, if the program calls MapWindow before the window has > >been reparented to the root it will get a XMapRequest with window= old > >decoration parent window and window set to the client. Handle event sets > >the window of the execution context to xany.window (parent in this case) > >if the parent window is not root. When this is a destroyed decoration it > >will be passed to AddWindow in the function called from HandleMapRequest. > >the suggested fix would be to modify the context to have the window of the > >MapRequest event set to the context before calling AddWindow if the > >trigger event is a MapRequest. (I'm not entirely sure on how > >CaptureAllWindows works, but I believe this logic would be ennouh to keep > >it working correctly.) > > > >>>3) Decide that Maps following Unmaps is a bad application behaviour and > >>>have the handling of Unmap check if the window is about to remap before > >>>deciding to destroy it. > >> > >>That's wrong. If a window is unmapped the window structure must > >>be destroyed. There is no reliable way to find out if the window > >>is remapped or if it was destroyed and a different window got the > >>same id. > >> > > > >The idea was to check for a MapRequest of FW_W_PARENT before reparenting > >the window, while the server is grabbed, and if sush event exists not > >unparent it. The problem is only if the window is mapped again before the > >client is reparented to root. > > > > Would this patch really break anything? It does not use the windowid of > the client, but only that of the decorations, and since the decorations > haven't been destroyed yet this can't be a reused window id. It does solve > the problem with the MapWindow immediatly after the UnmapWindow call, and > does so without triggering re-placement of the window. > > --- fvwm/events.c 20 Mar 2006 20:32:35 -0000 1.518 > +++ fvwm/events.c 29 Aug 2006 20:07:59 -0000 > @@ -3624,6 +3624,13 @@ > XUnmapWindow(dpy, > fw->wmhints->icon_window); > } > } > + else if (FCheckTypedWindowEvent( > + dpy, FW_W_PARENT(fw), MapRequest, &dummy)) > + { > + XMapWindow(dpy, te->xunmap.window); > + MyXUngrabServer(dpy); > + return; > + } > else > { > RestoreWithdrawnLocation(fw, False, Scr.Root);
I have committed a fix for this. At the end of HandleUnmapNotify, check for pending MapRequests for that window, replace the window and parent with the client window and root, then call dispatch_event immediately. (See attached patch). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
Index: events.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.c,v
retrieving revision 1.518
diff -u -B -b -u -r1.518 events.c
--- events.c 20 Mar 2006 20:32:35 -0000 1.518
+++ events.c 30 Aug 2006 09:12:20 -0000
@@ -3512,11 +3515,15 @@
int dstx, dsty;
Window dumwin;
XEvent dummy;
+ XEvent map_event;
const XEvent *te = ea->exc->x.etrigger;
int weMustUnmap;
Bool focus_grabbed;
Bool must_return = False;
+ Bool do_map = False;
FvwmWindow * const fw = ea->exc->w.fw;
+ Window pw;
+ Window cw;
DBUG("HandleUnmapNotify", "Routine Entered");
@@ -3545,6 +3552,8 @@
return;
}
}
+ cw = FW_W(fw);
+ pw = FW_W_PARENT(fw);
if (te->xunmap.window == FW_W_FRAME(fw))
{
SET_ICONIFY_PENDING(fw , 0);
@@ -3635,6 +3644,12 @@
}
XSync(dpy, 0);
MyXUngrabServer(dpy);
+ if (FCheckTypedWindowEvent(dpy, pw, MapRequest, &map_event))
+ {
+ /* the client tried to map the window again while it
+ * was still inside the decoration windows */
+ do_map = True;
+ }
}
destroy_window(fw);
if (focus_grabbed == True)
@@ -3644,6 +3659,14 @@
EWMH_ManageKdeSysTray(te->xunmap.window, te->type);
EWMH_WindowDestroyed();
GNOME_SetClientList();
+ if (do_map == True)
+ {
+ map_event.xmaprequest.window = cw;
+ map_event.xmaprequest.parent = Scr.Root;
+ dispatch_event(&map_event);
+ /* note: we really should handle all map and unmap notify
+ * events for that window in a loop here */
+ }
return;
}
signature.asc
Description: Digital signature
