On Wed, 30 Aug 2006, Dominik Vogt wrote:
On Tue, Aug 29, 2006 at 10:18:30PM +0200, Viktor Griph wrote:
[snip]
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.
But if the application has changed any window properties (like the
name etc.), fvwm does not notice.
But wouldn't fvwm still recieve and handle PropertyNotify for those
changes? If not, would triggering a recapture at that time be a solution
not forcing a re-placement?
Looking at the capture code I see no reason to not have AddWindow use the
etrigger.xmaprequest.window instead of the context window. That
change alone would make fvwm act like most other WMs to this kind
application, i.e. forgetting all about it.
--- 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);
/Viktor
