On Mon, Dec 5, 2011 at 10:56 PM, John Lindgren <john.lindg...@aol.com> wrote: > On 12/05/2011 02:22 AM, Tristan Van Berkom wrote: >> >> On Mon, Dec 5, 2011 at 4:18 PM, Tristan Van Berkom<t...@gnome.org> wrote: >>> >>> Hi John, >>> >>> I am responsible for a large part of your pain. >>> >>> And I'm also surprised that this code is not working for you. >>> >>> The last time I looked at size negotiation, the toplevel window >>> constraints >>> have always been based on the minimum-for-minimum request of the >>> window contents (minimum height for minimum width). >>> >>> However, some observations while running your test: >>> o The minimum size constraint of your window is correct, it's set to >>> about >>> 20 chars of width, this is the smallest size your window can be >>> (firing up your test case allows me to shrink the window to that >>> size) >>> o A *bad* ugly bug here is that your label does not ellipsize, what is >>> up with that ? How come your label wraps when it was not asked to >>> wrap ? >>> o If the label were configured to wrap, then it *must* require at least >>> the >>> minimum height for it's minimum width, however the broken label does >>> not require that width... instead when shrinking the window it wraps >>> out of view >>> o Heightening the window will give some random extra allocation to >>> the child label, showing the wrapped text... >>> >>> So, I can observe a behavioural change here, the toplevel window is >>> behaving actually quite nicely, it seems to be constraining the window >>> size to the minimum-for-minimum request, and then setting a default >>> size to the natural width/height request. >>> >>> So I'm attaching my version of your test case, actually except for >>> the label being somehow severely broken here, your code works >>> nicely... I added a line that says gtk_window_set_default_size() >>> and I think that will fix all your problems. >>> >>> Actually anyway I have an outdated branch of GTK+ here so I >>> suspect I'm just running into a *really bad* label bug which >>> probably never made it to any production release... >>> >>> In short, the behavioural change is that the default size of a >>> window is now also derived from the natural request of it's content, >>> you can easily override that by adding the 2 lines of code which >>> I added to your test case, no "waiting for realize" hacks involved. >> >> Clarification: in the code I sent here... I queried the minimum width >> of the label, ideally if you just want the window to show by default at >> it's minimum width, you should query the window itself, not one of >> it's children. > > > This works for resizable windows. For fixed-size windows, however, the > label still does not ellipsize. I am attaching another test case. > Uncomment line 8, and suddenly the label expands to its full, unellipsized > width again.
Interesting. The api around non-resizable windows needs clarification/more documentation. It should be noted that historically in GTK+2, non-user resizable windows are the corner case where windows are actually meant to 'shrink' down to the smallest possible size. However in GTK+3 now we have a natural and minimum size, I dont think it would make sense to shrink down to the minimum size on a non-resizable window, instead non-resizable windows should always fit the natural size (that seems to make sense). In order to limit the GtkLabel's natural size request (separate from it's minimum size request), I've added the 'max-width-chars' property. Sending you back a working test case ;-) I'll leave it to you to close the filed bug as a non-issue.
_______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
