Re: some 64bit cleanup on CVS head (XGetWindowProperty())
On Sun, Aug 27, 2006 at 10:25:33AM +0200, Harald Dunkel wrote: Harald Dunkel wrote: Hi folks, Attached you can find a patch to fix XGetWindowProperty in various sources. This makes at least Xine work _much_ better on 64bit Debian. PS: Better means: The decorations around the popups and the main window are correct. Okay, I've applied the patch. Can you please provide ChangeLog entries for it? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
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: Handling of MapRequests
On Sun, Aug 27, 2006 at 08:51:13PM +0200, Viktor Griph wrote: What is the reason to send the parent window in a map request if it's not root? This may cause a window to disappear if it were first unmapped, and then mapped again if fvwm did not reparent it back to the root window before destroying the old parent window (which will be the new window sent to add window in that case). I don't actually understand what you are trying to say. MapRequest ewvents are not sent by fvwm but generated by the X server and sent to fvwm. Is there anything that makes using the xmaprequest.window uncunditionally for all MapRequests? Or should the unmap nofify handler check for pending map requests of the window before destroying it in the first place? No, see my reply in that other thread. Can you please try to explain your question again? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Applied clicktofocuspassesclick patch.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/08/29 09:07:06 Modified files: . : ChangeLog NEWS fvwm : ewmh.c Log message: * Applied clicktofocuspassesclick patch.
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: some 64bit cleanup on CVS head (XGetWindowProperty())
Dominik Vogt wrote: Okay, I've applied the patch. Can you please provide ChangeLog entries for it? Sure, see attachment. Many thanx Harri diff -ur /tmp/fvwm-snap-20060829/ChangeLog fvwm-snap-20060829/ChangeLog --- /tmp/fvwm-snap-20060829/ChangeLog 2006-08-27 10:00:02.0 +0200 +++ fvwm-snap-20060829/ChangeLog2006-08-29 18:19:15.0 +0200 @@ -1,3 +1,11 @@ +2006-08-29 Harald Dunkel [EMAIL PROTECTED] + + * fvwm/icccm2.c: + * fvwm/gnome.c: + * fvwm/decorations.c: + fix offset and length args for XGetWindowProperty() + (to support 64bit architectures) + 2006-08-26 Viktor Griph [EMAIL PROTECTED] * NEWS: diff -ur /tmp/fvwm-snap-20060829/modules/ChangeLog fvwm-snap-20060829/modules/ChangeLog --- /tmp/fvwm-snap-20060829/modules/ChangeLog 2006-08-27 10:00:02.0 +0200 +++ fvwm-snap-20060829/modules/ChangeLog2006-08-29 18:19:16.0 +0200 @@ -1,3 +1,14 @@ +2006-08-29 Harald Dunkel [EMAIL PROTECTED] + + * FvwmScroll/GrabWindow.c: + * FvwmScript/Widgets/TextField.c: + * FvwmScript/Instructions.c: + * FvwmPager/x_pager.c: + * FvwmForm/ReadXServer.c: + * FvwmDragWell/xdndDragSource.c: + change offset and length args for XGetWindowProperty() to long + (to support 64bit architectures) + 2006-08-26 Viktor Griph [EMAIL PROTECTED] * FvwmPager/FvwmPager.h (pager_window): diff -ur /tmp/fvwm-snap-20060829/utils/ChangeLog fvwm-snap-20060829/utils/ChangeLog --- /tmp/fvwm-snap-20060829/utils/ChangeLog 2006-02-11 10:00:04.0 +0100 +++ fvwm-snap-20060829/utils/ChangeLog 2006-08-29 18:19:18.0 +0200 @@ -1,3 +1,8 @@ +2006-08-29 Harald Dunkel [EMAIL PROTECTED] + + * xselection.c: change offset and length args for XGetWindowProperty() + to long (to support 64bit architectures) + 2006-02-11 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de * changelog.vim: signature.asc Description: OpenPGP digital signature
CVS domivogt: * Updated ChangeLog.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/08/29 13:45:25 Modified files: . : ChangeLog modules: ChangeLog utils : ChangeLog Log message: * Updated ChangeLog.
