On Mon, Dec 5, 2011 at 4:18 PM, Tristan Van Berkom <t...@gnome.org> wrote:
> On Mon, Dec 5, 2011 at 9:21 AM, John Lindgren <john.lindg...@aol.com> wrote:
>> On 12/04/2011 04:02 AM, Emmanuele Bassi wrote:
>>> the status is always the same: bugs reported will be looked at by the
>>> gtk maintainers depending on time.
>> So the status at this moment is that no developers have time to look at bugs
>> reported by application developers.  Or is there something wrong with my
>> report in particular?
>>> the source of the issue is that gtk3 does not allow widget
>>> underallocations, unlike gtk2. underallocations were a huge source of
>>> edge cases, code complexity, and nasty bugs in gtk2 and when the time
>>> came to review the size negotiation implementation, and add support
>>> for height-for-width and width-for-height, keeping support for
>>> underallocations would have made the code balloon out of the
>>> maintainership capabilities of the gtk team - as well as introduce new
>>> and exciting bugs. this is why setting the minimum size using
>>> set_size_request() will not work in your case: the label's minimum
>>> size is bigger than the size you requested.
>>> long story short: if you want to set the minimum size on a label you
>>> can do it with the set_width_chars() method:
>>> http://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-width-chars
>> Thank you for the suggestion.  Unfortunately, when I tried it just now, that
>> method also no longer works in GTK+ 3.x.  Accordingly, I have reported this
>> problem also: https://bugzilla.gnome.org/show_bug.cgi?id=665560
> 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.

> Cheers,
>            -Tristan
gtk-app-devel-list mailing list

Reply via email to