GNOME Bugzilla – Bug 13296
Resizing window: success of request should be verified
Last modified: 2009-08-15 18:40:50 UTC
Package: gimp Version: 1.1.23 Name........: Peter Daum Email.......: gator@cs.tu-berlin.de Platform....: X86, Linux GIMP Version: 1.1.23 GTK Version.: 1.2.8 WM/Version..: fvwm 2.3.19 -- Other system notes: -- -- Problem description: After operations, that result in resizing the image window (shrink-wrap, crop ...) Gimp (or Gtk) obviously assumes, that the window has the requested size without checking the result. If for some reason the window size is unchanged, the window will be redrawn based on wrong assumptions about it's size. ICCCM 2.0 states: "Clients must be aware that there is no guarantee that the window manager will allocate them the requested size or location and must be prepared to deal with any size and location." -- -- How to repeat: (With fvwm 2.3.xx:) - Maximize the image window - invoke "View -> Shrink Wrap" (the window size will be unchanged, gimp will redraw the window in the upper left corner of the window) -- -- Other comments: Recent versions of fvwm don't allow clients to resize a window that is currently maximized. Originally, I had reported this as a bug to the fvwm developers, but it is intended as a feature; they might introduce a workaround in the future ... -- ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 10:54 ------- This bug was previously known as bug 13296 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=13296 Originally filed under the gimp product and general component. The original reporter (gator@cs.tu-berlin.de) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, egger@suse.de.
See also bug #22567 which may be a direct consequence of this one.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
This bug still exists in 1.2.3 and it makes Gimp unusable in a window manager that fixes sizes, such as the frame-based Ion (http://www.students.tut.fi/~tuomov/ion). Will this ever be fixed? I hate to use an inferior window manager just to run Gimp, especially when Ion's frame-based approach makes it IMHO the ideal window manager to work with Gimp as it reduces the clutter of Gimps 1001 windows (especially with the targetting feature that can put every Gimp window into the frame where I want it automatically). If you're looking for an easy way to reproduce and debug this bug, use Ion. Just crop an image an presto the canvas window breaks. Switch tools with tool option open and zap the tool option window is broken. There are more problems which you'll easily spot if you do a little work with Gimp under Ion.
This problem exists with several window managers, not only with Ion. Alas, most of the GIMP developers use only a few window managers and sometimes the GIMP (or GTK+) code contains some assumptions that are correct for some of the most common WMs but are not working with others. The original report was right about the ICCCM: the application should never assume that a request for resizing a top-level window has resulted in the expected size or location. The window manager is allowed and encouraged to adjust the size or location of the windows as appropriate. The safest way for an application to resize a top-level window (one that is controlled by the WM) is to query the X server for the new window geometry immediately after sending the request. This makes things a bit slower because querying the X server will flush all pending events, but this is the only way to avoid strange results. I do not know if we can fix this in 1.2.4, but we should at least try.
Will this ever be fixed? Yes, as soon as someone sends a patch for it!
Of course, when I wrote "we should try", I was including myself in the "we". ;-) As I suggested above, this bug and bug #22567 can probably be fixed by calling gdk_window_get_geometry() after resizing any top-level window. As far as I know, this has to be done on the GDK level because there is no GTK function that can flush the current events and query the X server for the current window geometry. Unfortunately, as you pointed out in bug #22567, the code that does the resizing of the image windows is not very clean or robust.
Before someone starts to waste time: a patch fixing this would consist mostly of code removal. We already have a "configure_event" handler which does its job, we just need to allow it to be invoked after resizing instead of trying to do the same manually.
Fixed in CVS HEAD using gtk_window_resize(). This function was not there in gtk+ 1.2 and was added for exactly the purpose we use it now because trying to acheive the same without it produced broken code like in this case. We should IMHO not try to fix this in 1.2. Closing this bug. 2003-01-07 Michael Natterer <mitch@gimp.org> Fixed bug #13296: * app/display/gimpdisplayshell.c (gimp_display_shell_shrink_wrap): don't do evil stuff but simply call gtk_window_resize(). Gtk+ will automatically place the window onscreen if it would be invisible after resizing. * app/display/gimpdisplayshell-callbacks.c (gimp_display_shell_canvas_configure): don't call gimp_dislpay_shell_scale_resize() to avoid recursion but do the two needed calls manually.
Forgot to actually close the bug.
*** Bug 22567 has been marked as a duplicate of this bug. ***
I'd like to hear from the Ion user as to whether this fixes his problems in 1.3. Cheers, Dave.
The fix is part of the stable release 1.2.4. Closing this bug.