After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 631699 - Change in behavior of under-allocation
Change in behavior of under-allocation
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other All
: Normal normal
: 3.0
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 627136
 
 
Reported: 2010-10-08 17:47 UTC by Owen Taylor
Modified: 2015-05-10 22:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Owen Taylor 2010-10-08 17:47:57 UTC
The behavior of GtkBox when not given enough space has changed. Say we have something like:

GtkWindow, set_size_request(600, 400)
  GtkHBox
   GtkMenuBar, packed expand=FALSE, fill=FALSE
   GtkDrawingArea, set_size_request(1000, 1000),
     packed expand=TRUE, fill=TRUE

(I haven't actually tested that particular example, coming from a misbehavior of VteTerminal inside gnome-terminal)

Behavior with gtk2:

 +------------------------------+
 |          GtkMenuBar          |
 +------------------------------+
 |                              |
 |         GtkDrawingArea       |
 |                              |
 |                              | 
 +------------------------------+

Behavior with gtk3:

 
 +....................................................+
 .           GtkMenuBar                               .
 +....................................................+
 .                                                    .
 .  GtkDrawingArea                                    .
 +---------------------------------+                  .
 |                                 |                  .
 |                                 |                  .
 |                                 |                  .
 |            GtkWindow            |                  .
 |                                 |                  .
 |                                 |                  .
 |                                 |                  .
 ----------------------------------+------------------+


I.e. - only a small portion of the GtkDrawingArea is visible. (Exactly what portion is visible may be wrong in the above picture - haven't verified in great detail)

While under-allocation is pathological - and many widgets don't handle it at all, it might be a good idea to try and preserve the gtk2 behavior to avoid breaking application layouts in a confusing way.

(I could be convinced otherwise - while the above layout seems inexplicable, if instead if had allocated it like:

 +---------------------------------+
 |           GtkMenuBar            |                  
 +---------------------------------+...................
 |                                 |                  .
 |                                 |                  .
 |                                 |                  .
 |                                 |                  .
 |                                 |                  .
 +---------------------------------+                  .                
 .                     DrawingArea                    . 
 .                                                    .
 .                                                    .
 .                                                    .
 ......................................................

With the DrawingArea lapping outside the bounds of the GtkWindow - then that might be a legitimate expression of a principle - "whatever size we are given - don't underallocate children"

I'm mostly filing this to make sure that if we decide to make this behavior change we do it intentionally and with deliberation and aren't scrambling to wonder if we should revert it after 3.0 has been released.)
Comment 1 Owen Taylor 2010-10-08 21:44:30 UTC
This actually may have more to do with gtk_widget_real_adjust_size_allocation() than GtkBox
Comment 2 Owen Taylor 2010-10-08 22:25:06 UTC
Before I put this down for the day, wanted to describe very briefly why this causes problems for gnome-terminal.

The basic problem is that the VTE widget in gnome-terminal reports its current size as its minimum size, but the toplevel has a smaller minimum size on it so that it can be resized smaller.

In GTK+-2.0, the VTE widget will be resized smaller because everything propagates down the smaller-than-minimum allocation, and the result will be that the VTE widget will pick up a new smaller size (from 100x30 to 90x25 or whatever)

In GTK+-3.0 the VTE widget just ends up centered at it's previous size.

So the obvious thing would seem to be to make the VTE widget use GTK+ 3 size request mechanisms to report it's current size as its preferred size and report the real minimum size.

However, this won't really work out because the mechanism for handling the "geometry_widget" for gtk_window_set_geometry(), as described in:

  https://bugzilla.gnome.org/show_bug.cgi?id=68668

Only work when the minimum size of the geometry widget are bigger than all the other minimum sizes in the window. I don't see any obvious fix with the current allocaiton behavior other than trying to fix 68668 in some fashion. Which would be a good thing, but I'm uncertain how hard it is. Will look into it some soon.
Comment 3 Javier Jardón (IRC: jjardon) 2011-02-02 13:42:44 UTC
Hello Owen,

now that bug #68668 is already fixed and vte is already ported to GTK+3, what is the status of this bug?
Comment 4 Matthias Clasen 2015-05-10 22:22:19 UTC
I think we can say that this won't be fixed back