Re: GTK 3 support status
- From: Tristan Van Berkom <tvb gnome org>
- To: John Lindgren <john lindgren aol com>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: GTK 3 support status
- Date: Mon, 5 Dec 2011 16:22:22 +0900
On Mon, Dec 5, 2011 at 4:18 PM, Tristan Van Berkom <tvb gnome org> wrote:
On Mon, Dec 5, 2011 at 9:21 AM, John Lindgren <john lindgren 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:
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
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
] [Thread Prev