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 642406 - GtkDialog size allocation issues
GtkDialog size allocation issues
Status: RESOLVED DUPLICATE of bug 729532
Product: gtk+
Classification: Platform
Component: .General
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
EL
Depends on:
Blocks:
 
 
Reported: 2011-02-15 18:38 UTC by Milan Crha
Modified: 2014-09-08 03:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test.c (3.11 KB, text/plain)
2011-02-15 18:38 UTC, Milan Crha
Details

Description Milan Crha 2011-02-15 18:38:47 UTC
Created attachment 180931 [details]
test.c

While working on bug #641011 comment #3 I tried to do the same in gtk+ only, and it results in this bug. The attached is my test "application", on which you can observe:

a) just run it makes the dialog too tall, totally unbalanced with respect of size request done by labels and its text. When I compile the same with gtk2 I get much nicer output, though label content doesn't re-wrap on window resize in gtk2 (which is fine for me).

b) [back with gtk3] when resizing and making window larger the text changes as expected, which is nice, but the window minimum height is not, so I cannot make window smaller in Y than it was the first time, which is kinda strange. I would expect, when it plays with label texts, that it will also recompute its own size constraints.

c) [this might be closely related to b] drag the window sizer to make window smaller, it's almost impossible, which is fine, but when I make it larger and then smaller in both axes, then I can make it smaller than it was (or the text wraps differently, somehow), so the ckeckbox is hidden under buttons now. I cannot reproduce it easily, though, it requires more tries sometimes. I'm just quickly moving the sizer in both X and Y directions, to make it smaller and then larger.
Comment 1 Matthias Clasen 2014-09-08 03:23:26 UTC

*** This bug has been marked as a duplicate of bug 729532 ***