GNOME Bugzilla – Bug 101968
(extended-layout) Height-for-width layout
Last modified: 2010-05-22 03:24:59 UTC
When line wrapping is enabled, GtkLabel tries to stop the text from occupying more than half of the available screen width. This is often not desirable behaviour, especially if the screen is quite narrow. In particular, it obviously means that strings with widths between 50% and 100% of the screen width will now be split onto multiple lines, whereas with line wrap disabled they would fit onto a single line. This can lead to strange-looking screen layouts with much wasted space. It would be helpful to have a mode where GtkLabel only splits lines when actually necessary: ie where a non-line-wrapping label would have truncated the text.
If you think about this some, you'll realize that there is no way to do better than the current GtkLabel without height-for-width geometry management. (Adding an expanded geometry-management interface with height-for-width is certainly a future possibility.) As it currently works, GtkLabel needs to say the minimum height *and* width that it needs. If that guess is that it needs 200 wide and 200 high, and then it ends up being 400 wide, it is still going to have a space 200 pixels high. So, all rewrapping to the wider width would give you is a big space underneath.
If we really need height-for-width geom mgmt then how does GtkTextView work? TextView uses the width-request property to specify the minimum amount of width that it requires. Then TextView will use its whole space allocation, wrapping at the allocated width expanding its height as needed. It refuses to shrink to less than width-request. If the width-request is unset then TextView requests the width of its widest line. Labels, on the other hand, wrap to a hard-coded width which is dependent on the current font. Overriding the width-request can change this minimum width, but the label ignores any additional space allocation. It doesn't expand to use extra space.
GtkTextView lives inside a GtkScrolledWindow, and is a completely different situation. Also, people don't generally consider it wrong when there is a bunch of space after some editable text. (To some extent the adjustments "interface" used by GtkScrolledWindow is a a height-for-width interface; it allows for multiple layout passes)
*** Bug 118045 has been marked as a duplicate of this bug. ***
*** Bug 120411 has been marked as a duplicate of this bug. ***
any progress on that one?
any progress ? This bug is especially annoying for WrappedLabel. +++ = window/container --- = Gtk2::WrappedLabel * at minimal size : ++++++++++++++++++++++++++++++ +----------------------------+ +- blabla gfdgdgfdg regfg my-+ +- word -+ +----------------------------+ ++++++++++++++++++++++++++++++ myword is cut which is normal and the text has two lines in order to be dipslayed which is fined. * when window width increase : +++++++++++++++++++++++++++++++++++++++++++++++++++ +---------------------------- + +- blabla gfdgdgfdg regfg my- + +- word - + +---------------------------- + +++++++++++++++++++++++++++++++++++++++++++++++++++ As you can see Gtk2::WrappedLabel doesn't follow the window width and the text has still 2 lines. The correct behaviour should be : +++++++++++++++++++++++++++++++++++++++++++++++++++ +-------------------------------------------------+ +- blabla gfdgdgfdg regfg myword -+ +-------------------------------------------------+ +++++++++++++++++++++++++++++++++++++++++++++++++++ As there's enough place, the text should become 1 line and myword should not longer be wrapped.
*** Bug 164461 has been marked as a duplicate of this bug. ***
*** Bug 168478 has been marked as a duplicate of this bug. ***
*** Bug 308273 has been marked as a duplicate of this bug. ***
In the meantime, is there any sort of workaround? This can be a very nasty bug, UI-wise....
*** Bug 329646 has been marked as a duplicate of this bug. ***
*** Bug 321373 has been marked as a duplicate of this bug. ***
I'm bitten by this bug too... A workaround when you know you won't be resized (for example if you run your app in fullscreen mode as I do) is to call gtk_widget_size_request with the width you'll be allocated (in my case, the width of the screen), and -1 as the height. Hope this helps someone...
My software team has just been hit by this bug as well. We are using it for labeling icons and the results are not good. It is really a problem for us. Any possibility of seeing it resolved? Thanks, Sean Kelley
If you happen to use Gtkmm, I do have a work around of sorts. The folks from VMware have a SF project that includes a Gtkmm library of widgets. One of them is WrapLabel: A GtkLabel subclass that can wrap to any width, unlike GtkLabel which has a fixed wrap point. It does this through a couple of tricks in the size_allocate and size_request handlers by using PangoLayout's height-for-width. It's contained inside VMware's open-source widget library located here: http://view.sourceforge.net/ We checked it out in a few different cases, and the word wrapping works OK even with labels positioned inside a Fixed. Hope that helps, Sean
Feedback from one of our devs on this libview WrapLabel: -- There's another side-effect to this implementation of wrapping. During the lifetime of size_allocate(), a new size requisition cycle is queued unless the next-width is equal to the current-width. This implicitly assumes that the container which holds the WrapLabel is going to reach a quiescent state where it always hands the same allocation to the child WrapLabel. But if one overrides a container's size_allocate() method, a common pattern would be to call the base class's size_allocate implementation [which sets one allocation value in each child], then do some custom repositioning [setting a different allocation in each child]. This would mean that it the allocation handed to each label never converges to a steady state. Infinite queue_resize()'s occur. -- Jorn Baayen has pointed out that to have this working properly, Gtk really needs a proper width-for-heith negotiation. Sean
The WrapLabel subclass from libview doesn't work in the case that the container holding the label has some kind of custom size_allocate() implementation which ends up calling size_allocate() more than once on each child. (e.g., first chain up to the container's base class method, then re-position children in the overridden method body). In this scenario, the WrapLabel detects that no two successive calls to its size_allocate handler contain the same values for the GtkAllocation, and it keeps endlessly requesting queue_resize() calls.
(In reply to comment #19) > The WrapLabel subclass from libview doesn't work in the case that the container > holding the label has some kind of custom size_allocate() implementation which > ends up calling size_allocate() more than once on each child. (e.g., first > chain up to the container's base class method, then re-position children in the > overridden method body). Note that if you provide a new size allocation algorithm you should not need to chain up to the base class method.
Created attachment 97601 [details] [review] [1/20] Introducing the GtkExtendedLayout interface gtk/Makefile.am | 2 + gtk/gtk.h | 1 + gtk/gtk.symbols | 14 +++ gtk/gtkenums.h | 9 ++ gtk/gtkextendedlayout.c | 284 +++++++++++++++++++++++++++++++++++++++++++++++ gtk/gtkextendedlayout.h | 103 +++++++++++++++++ 6 files changed, 413 insertions(+), 0 deletions(-)
git-send-bugzilla died... trying again.
Created attachment 97603 [details] [review] [1/20] Introducing the GtkExtendedLayout interface gtk/Makefile.am | 2 + gtk/gtk.h | 1 + gtk/gtk.symbols | 14 +++ gtk/gtkenums.h | 9 ++ gtk/gtkextendedlayout.c | 284 +++++++++++++++++++++++++++++++++++++++++++++++ gtk/gtkextendedlayout.h | 103 +++++++++++++++++ 6 files changed, 413 insertions(+), 0 deletions(-)
Created attachment 97604 [details] [review] [2/20] Implementing GtkExtendedLayout for GtkBin gtk/gtkbin.c | 142 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 138 insertions(+), 4 deletions(-)
Created attachment 97605 [details] [review] [3/20] GtkAlignment: Using GtkBorder for padding gtk/gtkalignment.c | 85 +++++++++++++++++++++++++--------------------------- 1 files changed, 41 insertions(+), 44 deletions(-)
Created attachment 97606 [details] [review] [4/20] GtkAlignment: Implementing GtkExtendedLayout gtk/gtkalignment.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 53 insertions(+), 1 deletions(-)
Created attachment 97608 [details] [review] [5/20] GtkButton: Implementing GtkExtendedLayout gtk/gtkbutton.c | 133 ++++++++++++++++++++++++++++++++++--------------------- 1 files changed, 83 insertions(+), 50 deletions(-)
Created attachment 97609 [details] [review] [6/20] GtkFrame: Implementing GtkExtendedLayout gtk/gtkframe.c | 68 ++++++++++++++++++++++++++++++++++++++++++-------------- 1 files changed, 51 insertions(+), 17 deletions(-)
Created attachment 97610 [details] [review] [7/20] GtkCellView: Implementing GtkExtendedLayout gtk/gtkcellview.c | 105 +++++++++++++++++++++++++++++++++++++++-------------- 1 files changed, 77 insertions(+), 28 deletions(-)
Created attachment 97611 [details] [review] [8/20] GtkCellRendererText: Implementing GtkExtendedLayout gtk/gtkcellrenderertext.c | 41 ++++++++++++++++++++++++++++++++++++++++- 1 files changed, 40 insertions(+), 1 deletions(-)
Created attachment 97612 [details] [review] [9/20] GtkScrolledWindow: Implementing GtkExtendedLayout gtk/gtkscrolledwindow.c | 46 ++++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 42 insertions(+), 4 deletions(-)
Created attachment 97613 [details] [review] [10/20] GtkSocket, GtkPlug: Implementing GtkExtendedLayout gtk/gtkplug-x11.c | 26 +++++++++++++++++++ gtk/gtkplug.c | 17 +++++++++++- gtk/gtkplugprivate.h | 9 ++++++ gtk/gtksocket-x11.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++- gtk/gtksocket.c | 57 ++++++++++++++++++++++++++++++++++++++++++- gtk/gtksocketprivate.h | 9 ++++++ 6 files changed, 178 insertions(+), 4 deletions(-)
Created attachment 97614 [details] [review] [11/20] GtkTreeView, GtkTreeViewColumn: Implementing GtkExtendedLayout gtk/gtktreeprivate.h | 7 ++ gtk/gtktreeview.c | 142 +++++++++++++++++++++++++++++++++++++++-------- gtk/gtktreeviewcolumn.c | 130 +++++++++++++++++++++++++++++++------------ gtk/gtktreeviewcolumn.h | 5 +- 4 files changed, 221 insertions(+), 63 deletions(-)
Created attachment 97615 [details] [review] [12/20] GtkLabel: Support ellipses in rotated labels gtk/gtk.symbols | 2 + gtk/gtklabel.c | 225 +++++++++++++++++++++++++++++++++++++++++------------- gtk/gtklabel.h | 3 + 3 files changed, 176 insertions(+), 54 deletions(-)
Created attachment 97616 [details] [review] [13/20] GtkLabel: Implement GtkExtendedLayout gtk/gtklabel.c | 134 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 132 insertions(+), 2 deletions(-)
Created attachment 97617 [details] [review] [14/20] GtkLabel: Test rotated text with ellipses tests/testellipsise.c | 121 +++++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 113 insertions(+), 8 deletions(-)
Created attachment 97618 [details] [review] [15/20] GtkHBox, GtkVBox: Implement GtkExtendedLayout gtk/gtkhbox.c | 379 +++++++++++++++++++++++++++++++++--------------------- gtk/gtkprivate.h | 4 + gtk/gtkvbox.c | 345 +++++++++++++++++++++++++++++++------------------- 3 files changed, 449 insertions(+), 279 deletions(-)
Created attachment 97619 [details] [review] [16/20] GtkHBox: Basic and broken baseline alignment gtk/gtk.symbols | 2 + gtk/gtkhbox.c | 273 +++++++++++++++++++++++++++++++++++++++++++++++++++---- gtk/gtkhbox.h | 9 +- 3 files changed, 263 insertions(+), 21 deletions(-)
Created attachment 97620 [details] [review] [17/20] GtkTable: Implement GtkExtendedLayout gtk/gtk.symbols | 2 + gtk/gtktable.c | 254 ++++++++++++++++++++++++++++++++++++++++++++++--------- gtk/gtktable.h | 4 + 3 files changed, 220 insertions(+), 40 deletions(-)
Created attachment 97621 [details] [review] [18/20] Provide tests for the extended layout manager tests/Makefile.am | 14 +- tests/autotestextendedlayout.c | 702 +++++++++++ tests/testextendedlayout.c | 2654 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 3369 insertions(+), 1 deletions(-)
Created attachment 97622 [details] [review] [19/20] Add change logs of the extended-layout branch ChangeLog.gtk-extended-layout | 438 ++++++++++++++++++++++++++ docs/reference/ChangeLog.gtk-extended-layout | 6 + 2 files changed, 444 insertions(+), 0 deletions(-)
Created attachment 97623 [details] [review] [20/20] Update documentation, incomplete docs/reference/gtk/gtk-docs.sgml | 2 + docs/reference/gtk/gtk-sections.txt | 20 ++++++ docs/reference/gtk/gtk.types | 1 + docs/reference/gtk/tmpl/gtkextendedlayout.sgml | 85 ++++++++++++++++++++++++ 4 files changed, 108 insertions(+), 0 deletions(-)
*** Bug 492988 has been marked as a duplicate of this bug. ***
Comment on attachment 97603 [details] [review] [1/20] Introducing the GtkExtendedLayout interface >+GtkExtendedLayoutFeatures gtk_extended_layout_get_features (GtkExtendedLayout *layout); >+gint gtk_extended_layout_get_height_for_width (GtkExtendedLayout *layout, >+ gint width); >+gint gtk_extended_layout_get_width_for_height (GtkExtendedLayout *layout, >+ gint height); >+void gtk_extended_layout_get_natural_size (GtkExtendedLayout *layout, >+ GtkRequisition *requisition); >+gint gtk_extended_layout_get_baselines (GtkExtendedLayout *layout, >+ gint **baselines); >+void gtk_extended_layout_set_baseline_offset (GtkExtendedLayout *layout, >+ gint offset); >+gint gtk_extended_layout_get_single_baseline (GtkExtendedLayout *layout, >+ GtkBaselinePolicy policy); >+void gtk_extended_layout_get_padding (GtkExtendedLayout *layout, >+ GtkBorder *padding); I am slightly concerned that these method names are going to conflict with existing classes. This is mainly a problem in a language binding such as python where the last part of method name "get_padding" is part of the public API. Some of them are unlikely to clash, but get_padding/get_natural_size/get_features are high risk ones. Could they perhaps be renamed/namespaced somehow?
Comment on attachment 97605 [details] [review] [3/20] GtkAlignment: Using GtkBorder for padding This can probably go in right away.
(In reply to comment #44) > I am slightly concerned that these method names are going to conflict with > existing classes. > This is mainly a problem in a language binding such as python where the last > part of method name "get_padding" is > part of the public API. Yes, looking in devhelp, I see that it conflicts with gtk_misc_get_padding() and gtk_alignment_get_padding(). We should check for each new function, I guess. For padding, gtk_extended_layout_get_padding() could be renamed to gtk_extended_layout_get_extended_padding() But I wonder if this is meant to replace those old get_padding() functions.
Guess gtk_extended_layout_get_baselines, gtk_extended_layout_set_baseline_offset, gtk_extended_layout_get_single_baseline and gtk_extended_layout_get_padding even could be left out on a first merge step -- if we agree, that GObject interfaces are extensible -- as they are needed for baseline alignment, which doesn't really work yet. More in the extended-layout summary I'll send to gtk-devel-list tomorrow morning (CET).
Waiting for your summary to review! Thanks.
(In reply to comment #44) > Some of them are unlikely to clash, but > get_padding/get_natural_size/get_features are high risk ones. Could they > perhaps be renamed/namespaced somehow? Well, actually the functions are in a namespace already: "gtk_extended_layout". If some bindings do not relect this and get name conflicts, their concept of interface support is broken, I guess. Adding even more namespace to the C names of those functions, would even more polute the C code with namespace clutter.
> If some bindings do not relect this and get name conflicts, their concept of > interface support is broken, I guess. I don't think so. Python, Java, and C++ will all have the problem: that label.get_padding() is ambiguous (the compiler/interpreter can't decide whether to call GtkLabel::get_padding() or GtkExtendedLayout::get_padding(). At best it will be confusing to the developer. It should be avoided in C just as much as it should be avoided for the language bindings. And by fixing it in C you keep the language bindings consistent.
And there (In reply to comment #50) > > If some bindings do not relect this and get name conflicts, their concept of > > interface support is broken, I guess. > > I don't think so. Python, Java, and C++ will all have the problem: > that label.get_padding() is ambiguous (the compiler/interpreter can't decide > whether to call GtkLabel::get_padding() or GtkExtendedLayout::get_padding(). At > best it will be confusing to the developer. It should be avoided in C just as > much as it should be avoided for the language bindings. And by fixing it in C > you keep the language bindings consistent. And there we are again in the GObject interface discussion. It seems that many binding authors see GObject interfaces as part of a class hierachy - similiar to the concept found in Java in C#, but as far as I understand, GObjects interfaces take the side-by-side, the aspect oriented route, (XP)COM inspired. You attach them to a class as attaching aspects in AOP. To use an interface you explicitly cast to that interface, as for instance: MAMAN_BAR_GET_INTERFACE, IUnknown::QueryInterface... Forcing C programmers to use 40+ letter could be considered a special form of violence.
(In reply to comment #46) > (In reply to comment #44) > > I am slightly concerned that these method names are going to conflict with > > existing classes. > > This is mainly a problem in a language binding such as python where the last > > part of method name "get_padding" is > > part of the public API. > > Yes, looking in devhelp, I see that it conflicts with gtk_misc_get_padding() > and gtk_alignment_get_padding(). We should check for each new function, I > guess. > > For padding, > gtk_extended_layout_get_padding() > could be renamed to > gtk_extended_layout_get_extended_padding() > > But I wonder if this is meant to replace those old get_padding() functions. Yes, in a perfect world we'd never had gtk_alignment_get_padding() or gtk_misc_get_padding() - we'd just have gtk_widget_get_padding with a signature similiar to gtk_extended_layout_get_padding(). While I could agree on gtk_extended_layout_get_extended_features() or even better gtk_extended_layout_get_layout_features(), I don't feel happy with gtk_extended_layout_get_extended_padding(): What's the "extendend"-ness of this padding?
http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00145.html
> You attach them to a class as attaching aspects in AOP. To use an interface you > explicitly cast to that interface, as for instance: MAMAN_BAR_GET_INTERFACE, > IUnknown::QueryInterface... Higher-level languages don't need the cast, and that's good. The way that bindings are using this is entirely natural. You can make life difficult for them, or not. > Forcing C programmers to use 40+ letter could be considered a special form of > violence. This is not going to be used very often. The function names are already very long, but that's not the fault of the language bindings.
Perl binding has no such issues. If other language bindings have such issue(In reply to comment #50) > > If some bindings do not relect this and get name conflicts, their concept of > > interface support is broken, I guess. > > I don't think so. Python, Java, and C++ will all have the problem: > that label.get_padding() is ambiguous (the compiler/interpreter can't decide > whether to call GtkLabel::get_padding() or GtkExtendedLayout::get_padding(). Perl binding has no such issues. If other language bindings have such issues, they've these issues not just there but in much more places regarding gtk+... Such bindings would be broken...
(In reply to comment #55) > Perl binding has no such issues. If other language bindings have such issue(In > reply to comment #50) > > > If some bindings do not relect this and get name conflicts, their concept of > > > interface support is broken, I guess. > > > > I don't think so. Python, Java, and C++ will all have the problem: > > that label.get_padding() is ambiguous (the compiler/interpreter can't decide > > whether to call GtkLabel::get_padding() or GtkExtendedLayout::get_padding(). > > Perl binding has no such issues. just to clarify: perl bindings have this issue as well, unless you use the extensive notation for sub calling which removes all ambiguity: $widget = Gtk2::Label->new(); Gtk2::ExtendedLayout->get_padding($widget); Gtk2::Label->get_padding($widget); but, frankly, is ugly and it also utterly breaks the OO approach used to write the bindings themselves. just because there is more than one way to do it, it does not mean that some ways should be used. namespace collision in high-level languages has been avoided by glib and gtk+ until now: let's not just start breaking it because of line length.
Ignore the noise: Just cleaning up my user page by assigning the proper state to that accidential attachment. :-D
Is there any news on this bug ?
(In reply to comment #58) > Is there any news on this bug ? CC yourself; you'll hear when there is news.
Created attachment 117998 [details] [review] [1/3] fix problems with GtkLabel extended layout see extended commentary at http://permalink.gmane.org/gmane.comp.gnome.gtk+.devel.general/15790
Created attachment 117999 [details] [review] [2/3] more work on GtkLabel extended layout support see commentary at http://permalink.gmane.org/gmane.comp.gnome.gtk+.devel.general/15790 http://permalink.gmane.org/gmane.comp.gnome.gtk+.devel.general/15792
Created attachment 118000 [details] [review] [3/3] GtkViewport: add extended layout support see commentary at http://permalink.gmane.org/gmane.comp.gnome.gtk+.devel.general/15791
*** Bug 585195 has been marked as a duplicate of this bug. ***
is there any maintainer to review the patched attached? Thanks for your support.
Please don't let this patch rot ! It's been open for too long to see this work wasted !
Subscribing with company address to keep an eye on this.
Any status update?
Hi, I've been looking into the native-layout branch for a couple days now and I think I have a good grasp on the overall patch, from my point of view its all very doable but there is at least one fundamental issue with the approach that needs to be addressed so far. At some point in history the API went from this: void gtk_extended_layout_get_natural_size (GtkExtendedLayout *layout, GtkRequisition *natural_size); To this: void gtk_extended_layout_get_desired_size (GtkExtendedLayout *layout, GtkRequisition *minimum_size, GtkRequisition *natural_size); From my understanding this was done to simplify code in implementing classes as was originally proposed in Havoc's mail: http://www.mail-archive.com/gtk-devel-list@gnome.org/msg06739.html Unfortunately while it makes perfect sense to do it that way when writing a new API; that is probably not going to work for GTK+ - the singular reason being I cant think of how it can be done without breaking the functionality of existing size_request()s. The short description to the problem, or the "bottom line" as I understand it is that when gtk_extended_layout_get_desired_size() is called on a third party widget that implements ->size_request, there is no way for GTK+ to know how to prefer the third party size_request, whether its decided by a third party widget or by a signal connection to a GTK+ widget. Going back to the ->get_natural_size() API is going to allow for both values to be consulted independently and thus allow containers to take into consideration minimum sizes specified by users or by derived widgets. As this is going to be a drastic revert on the branch - I was hoping someone might have some insight on these issues, if they ever came up before - and what plans did people have to address them at the time (this patch is now dating from 2005 and its near impossible for me to find and read all the related emails at this point). -Tristan PS: What follows here just a more in depth description of how its currently implemented and what I'm seeing going wrong: - gtk_widget_size_request () reroutes the calls to GtkExtendedLayout api (so that the new extended layout API for newer widgets is consulted for size requests by containers that dont use the new API). - GtkWidget implements GtkExtendedLayout and emits "size-request" as a base implementation of ->get_desired_size (); (NOTE "size-request" here will only be emitted as a default for widgets that dont implement the extended layout) - New extended layout savy containers use extended layout instead of "size-request" So first noticable problem with this is that if some user code connects to "size-request" and does anything there - that code will be broken because "size-request" will stop being fired for some widgets. The second problem is worse, consider this heirarchy: GtkWindow (GtkWindow doesn't implement extended layout; GtkBin class does). | +- GtkLabel (implements extended layout) In this scenario GtkWindow is an extension of GtkBin, GtkBin as its default implementation simply routes the ->get_natural_size() to GtkBin->child, in this case a GtkLabel. In this scenario the the size_request() vfunc that GtkWindow installed will never be called because GtkBin already avoided defaulting to the emission of a "size-request" signal. One thought I had for saving this api was to try the size-request first, but that comes with some other problems, one of them being an inconsistency across size_request() implementations; some of them fill the requisition; some of them assign their own widget->requisistion and GTK+ takes care of caching it inside the gtk_widget_size_request() semantics.
Crisis averted - no need to change any API so far as I can see. Sorry to cause any alarm, the branch was behaving as I described though; missing out on third party size requisitions (either set in signal callbacks or by derived classes). To solve the "size-request" issue without changing the API, I moved the call to g_signal_emit ( .. "size-request" ) back to gtksizegroup.c:do_size_request(), and there in do_size_request() I adjusted the strategy taken to compute/cache the initial requisition: The default GtkWidgetClass->get_desired_size() implementation sets both requisitions to -1, -1, then when calculating/caching the initial minimum/natural sizes we take this approach: 0.) force widget->requisition = -1, -1 1.) emit "size-request" directly on widget->requisition 2.) next call ->get_desired_size() 3.) base minimum size as the maximum of both returned minimums 4.) allow the size-request minimum also to act as a minimum value for the initially computed/cached natural size. The rule for this to work is that gtk_extended_layout_get_desired_size() should never be called directly on a GtkWidget, it must ofcourse pass through gtk_widget_get_desired_size() which does the size_request thing and so on (actually this was already a requirement for ->requisition caching to work at all - but the implementations were still disregarding that in most places - which made this unclear, I'll make sure to document that properly). Anyhow, I've pushed into the branch a merge from master and then these initial changes to how size-request is to be taken into account, I also tagged the branch: TRISTAN_NATIVE_LAYOUT_START before applying anything at all.
Renaming because this is where all the general extended-layout stuff is being tracked. It's all in the native-layout branch, with lots of recent work by Tristan: http://git.gnome.org/browse/gtk+/log/?h=native-layout He has also blogged about it, for instance here: http://blogs.gnome.org/tvb/2010/04/13/extending-the-layout-for-gtk/#comments
*** Bug 104188 has been marked as a duplicate of this bug. ***
A patch has been prepared and is available for review under the 'native-layout-incubator' branch. The patch is not too big, it touches size groups/gtkwidget and a few widgets, mostly GtkBox and GtkLabel. I does introduce the new geometry management to the current GTK+ core in safe and compatible way. More details available in my message to the list: http://mail.gnome.org/archives/gtk-devel-list/2010-April/msg00070.html
Target Milestone -> 3.0
This has been fixed as part of the extended layout work that Tristan has done for 3.0.