GNOME Bugzilla – Bug 68668
Fix handling of geometry widget
Last modified: 2010-10-11 18:16:50 UTC
From gtkwindow.c:gtk_window_compute_hints(): /* FIXME: This really isn't right. It gets the min size wrong and forces * callers to do horrible hacks like set a huge usize on the child requisition * to get the base size right. We really want to find the answers to: * * - If the geometry widget was infinitely big, how much extra space * would be needed for the stuff around it. * * - If the geometry widget was infinitely small, how big would the * window still have to be. * * Doing that, would be a bit of a mess here. */ We _could_ do things here like fake the usize temporararily of the geometry widget to 10000 and 0, but that requires munging of private flags to prevent infinite size request loops. Also, there is no current way to set the height in terms of the base/width_inc/height_inc of the widget, which is really wrong for parse_geometry() and is highly inconvenient for applications that want to use the geometry widget feature.
Moving non-critical and hard-to-fix bugs to 2.0.2
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
*** Bug 137822 has been marked as a duplicate of this bug. ***
Created attachment 172032 [details] [review] Fix handling of the geometry widget The geometry widget feature of gtk_window_set_geometry_hints() has never really worked right because the calculation that GTK+ did to compute the base size of the window only worked when the geometry widget had a larger minimum size than anything else in the window. Setup: * Move the GtkSizeGroup private functions to a new private header gtksizegroup-private.h * Add the possibilty to pass flags to _gtk_size_group_queue_resize(), with the flag GTK_QUEUE_RESIZE_INVALIDATE_ONLY to suppress adding the widget's toplevel to the resize queue. * _gtk_container_resize_invalidate() is added to implement that feature * _gtk_widget_override_size_request()/_gtk_widget_restore_size_request() allow temporarily forcing a large minimum size on the geometry widget without creating resize loops. GtkWindow: * Compute the extra width/height around the geometry widget correctly; print a warning if the computation fails. * Always make the minimum size at least the natural minimum size of the toplevel; GTK+ now fails badly with underallocation. * Always set the base size hint; we were failing to set it properly when the specified minimum size was overriden, but it's harmless to always set it. Tests: * New test 'testgeometry' that replaces the 'gridded geometry' test from testgtk. The new test is roughly similar but creates a bunch of windows showing different possibilities. * The testgtk test is removed. No need to have both.
Review of attachment 172032 [details] [review]: Seems to work great. Thanks for the test cases. ::: gtk/gtkwidget.c @@ +8818,3 @@ +} + +/** These two don't seem to appear in any header ? Should perhaps add them in gtkprivate.h, where most of the private GtkWidget apis are nowadays.
(In reply to comment #5) > Review of attachment 172032 [details] [review]: > > Seems to work great. Thanks for the test cases. > > ::: gtk/gtkwidget.c > @@ +8818,3 @@ > +} > + > +/** > > These two don't seem to appear in any header ? > Should perhaps add them in gtkprivate.h, where most of the private GtkWidget > apis are nowadays. Didn't know about gtkprivate.h - would you prefer if I moved the gtksizegroup private functions there rather than adding gtksizegroup-private.h for two functions and an enum?
No, I actually prefer to move to a private-header-per-widget setup, instead of a single giant gtkprivate.h
Attachment 172032 [details] pushed as 88cf547 - Fix handling of the geometry widget (with header additions now in the right patch)