Re: MapWindow directly after UnmapWindow
On Wed, Aug 30, 2006 at 11:20:27AM +0200, Dominik Vogt wrote: 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). I can also confirm that the attached fix seems to fix the fpga_editor related problem I reported as bug 4062 in the bugtracker. So it would be good if someone could close the bug report. /Andreas
Re: MapWindow directly after UnmapWindow
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.
--- fvwm/events.c 20 Mar 2006 20:32:35 - 1.518
+++ fvwm/events.c 29 Aug 2006 20:07:59 -
@@ -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);
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: MapWindow directly after UnmapWindow
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 - 1.518
+++ fvwm/events.c 29 Aug 2006 20:07:59 -
@@ -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.c20 Mar 2006 20:32:35 - 1.518
+++ events.c30 Aug 2006 09:12:20 -
@@ -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 @@
Re: MapWindow directly after UnmapWindow
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? 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. I'm most interested in knowing if there would be any downside with solution 3, in which case solution 2 is the one to take. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: MapWindow directly after UnmapWindow
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. I'm most interested in knowing if there would be any downside with solution 3, in which case solution 2 is the one to take. /Viktor
Re: MapWindow directly after UnmapWindow
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) 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. I'm most interested in knowing if there would be any downside with solution 3, in which case solution 2 is the one to take. /Viktor
