GTK 2.4 freezes with xfwm-4.4.1: When setting with gtk_window_set_geometry_hints e.g. a minimal width for a gtk-Window gtk may freeze until a move or resize is done by mouse. Reason: When filling the gtk-window with content gtk sends xConfigureRequest events with a width which is maybe lesser than the miminal width (set by gtk_window_set_geometry) and is waiting for a ConfigureNotify-Event. But there is no ConfigureNotify-Event created by the xfwm4 (which is imho the bug) and also not created by the x-server (because the x-server get's from the xfwm4 a modified xConfigureRequest with the minimal width and the gtk-window has already this minimal width, so the x-server does nothing).
Created attachment 1396 clears bits in the changes mask for moving/resizing windows If there is a minimal with for a window being set and there is a XConfigureRequest with a width that went below this minimal width there must be a synthetical ConfigureNotify created by xfwm. This Patch modifies client.c in that way that bits of the mask for moves/resizes are also cleared when no move/resize is done.
Created attachment 1397 sorry, the former patch doesn't work correctly Does the same as the former patch except it checks also moves/resizes which came from the gtk-application
Comment on attachment 1396 clears bits in the changes mask for moving/resizing windows This patch doesn't work correctly, look at the Attachment 1397
Do you have any simple reproducer of this?
This patch breaks a lot of things and doesn't work for me, and I am not sure what it is supposed to fix.
Created attachment 1405 gtk-program generating the error which should be corrected by the supplied patch With this program a X-ConfigureRequest is generated and the xfwm does not answer with a synthetical ConfigureNotify, which is imho a bug. Please see the comments in the attached programm. Additional Comment: By the XResizeWindow-Call the XServer generates a ConfigureRequest with a width of 300. The XFWM4 modifies this width to 400 (because of the miminal width of 400) but does not honor that the acutal width of the window is already 400. Here is the Bug!. Modifying a value in a XConfigureRequest means also to take care if there is no change to the window, and if so: Generate a synthetical X-ConfigureNotify.
Comment on attachment 1405 gtk-program generating the error which should be corrected by the supplied patch Sorry an #include <gdk/gdkx.h> should be added to the testprog.c to compile and link correctly
The test program is doing a resize with sizes smaller than the minimum set, so no resize occurs, why should that generate a synthetic notify event? The patch breaks a lot more than it fixes, so I need to be convinced of its usefulness.
(In reply to comment #8) > The test program is doing a resize with sizes smaller than the minimum set, so > no resize occurs, why should that generate a synthetic notify event? Due to 3 Reasons: (1) GTK does not remember himself that there is a minimum width, so in some odd cases, e.g. when you fill a existing GTK-Window (fixed width) with GTK-Widgets Gtk tries to adjust the window size to the content with configureRequests and is waiting (not allways) for a configure notify, which causes in my big fat application freezes in the gui. (2) If there is no WM present, the x-server generates a configure notify event. But with xfwm the x-server recognizes that there is a event redirection and waits for the WM to genereate a synthetical configure notify. (3) (The most important) In the ICCCM Section 4.1.5 it says (http://www.tronche.com/gui/x/icccm/sec-4.html#s-4.1.4) .... If the window manager decides to respond to a ConfigureRequest request by: - Not changing the size, location, border width, or stacking order of the window at all. A client will receive a synthetic ConfigureNotify event that describes the (unchanged) geometry of the window. The (x,y) coordinates will be in the root coordinate system, adjusted for the border width the client requested, irrespective of any reparenting that has taken place. The border_width will be the border width the client requested. The client will not receive a real ConfigureNotify event because no change has actually taken place. > > The patch breaks a lot more than it fixes, so I need to be convinced of its > usefulness. > What does it break? Where do you think there could be disadvantages? Greetings Andreas
(In reply to comment #9) > (3) (The most important) > In the ICCCM Section 4.1.5 it says > (http://www.tronche.com/gui/x/icccm/sec-4.html#s-4.1.4) I agree > > The patch breaks a lot more than it fixes, so I need to be convinced of its > > usefulness. > > > What does it break? Where do you think there could be disadvantages? Humm, thing is the patch did not apply, so I applied it manually and it is not a unified diff... So I probably miss one part regarding initialization of px, py, etc. Seems to work, I'll commit on trunk and see.
Applied on stable branch xfce_4_4 too. Thanks!