Re: GtkSizeGroup breakage (was Re: questions re: aux info, size request)

On Tue, 2010-09-14 at 12:45 -0400, Matthias Clasen wrote:
> This is indeed quite a brain teaser.
> I don't think your current approach of incrementally bumping the size
> group requisition does even work correctly. How does the size group
> requisition ever become smaller again ? The pre-hfw sizegroup code
> always looped over all widgets to determine the size group
> requisition, which seems to me the only way to make things work.
> I'll attach a simple example that shows the problem with incremental
> bumping. If you use the hpaned to make the long label unwrap
> completely, the height request does not get reduced to a single line
> height, as you can see by using the vpaned.

Thankfully the size groups are not broken in exactly the way that
we suspected (testgtk's size group test shows that we do indeed
reset the requested sizes for every resize queued on the group).

As a general wrap-up of this issue, as we discussed on irc there
is no way we can accurately group the sizes of height-for-width
(or width-for-height) widgets (at least for widgets that actually
make the trade).

Commit cc243d5887294c760492e43c0330eb5e2c3358cb adds the 
following text to the size-group documentation describing the issue:

  Note that only non-contextual sizes of every widget are ever consulted
  by size groups (since size groups have no knowledge of what size a
  widget will be allocated in one dimension, it cannot derive how much
  height a widget will receive for a given width). When grouping widgets
  that trade height for width in mode %GTK_SIZE_GROUP_VERTICAL or 
  %GTK_SIZE_GROUP_BOTH: the height for the minimum width will be the
  requested height for all widgets in the group.

For what its worth, size groups will still work fine with
widgets that are configured to have a static size (not wrap)
or for growing widgets that do not trade sizes (like ellipsizing

Also pushing the fix that synchronizes natural sizes along with
minimum sizes (commit d370aee7fd0605b47740f39971ef1a736717d760).

I think that pretty much closes the issues we've found with
size groups.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]