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);
/Viktor
