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

[Tristan Van Berkom <tristanvb openismus com>]

On Sun, 2010-09-12 at 01:01 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Sun, Sep 12, 2010 at 12:45 AM, Tristan Van Berkom
> <tristanvb openismus com> wrote:
> > While on this topic, there's this XXX comment I left dangling
> > in gtksizegroup.c:
> >   http://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n677
> >
> > I was thinking maybe that for all the widgets in a group to be
> > effectively the same size, maybe we should be basing the minimum
> > base requests from the natural requests of all widgets in a group.
> 
> I would expect that GtkSizeGroup caused all widgets in the group to
> request a min size of the largest min size in the group, and a natural
> size of the largest natural size in the group. Then it Just Works,
> right? Is there a reason that only one of min or natural can be picked
> for size group?

Ok this morning I wrote up a straight-forward patch that modifies the
size-group code to take both minimum and natural requests into
account... 

In doing so I opened a can of worms... to phrase the problem accurately;
size-groups can only function normally under the assumption that every
contextual height-for-width request made on the widget was a request
which will be used directly to determine it's allocation.

So for instance things will break when something like this happens:

   a.) Container requests minimum and natural width
   b.) Container requests height for the minimum width
   c.) Container requests height for an arbitrary width
       which fits inside the container's allocation
   d.) Container then allocates a height based on the 
       last request (contextual to the allocated width).

In this scenario, GtkSizeGroup height values are needlessly grown
after step b... which may or may not have been a pertinent request;
however the api does not mandate that the container not check the
height for the minimum width for whatever reason the container desires.
(I'm not even convinced that step b here should be discouraged, it may
very well be a useful step for some containers).

Some thoughts:

  - maybe only the non-contextual requests should be used with
    size-groups ? 

    No; because that leaves out one dimension in every case.

  - maybe the GtkSizeRequestIface should distinguish between a widget's
    request and allocation phase ?

    Again most probably No; the idea here would be to only use the
    contextual request for size groups when requested _for_allocation()
    (or by checking some widget flag that we are in the allocation
    phase)... this would have a downside of queueing a resize on all the
    group widgets from the allocation phase: intensely iterative and
    would slow things down... if not lock-up GTK+ completely.

  - maybe we should say that you should never request a contextual
    height for a width you are not sure will be actually allocated ?

    For reasons I outlined in the above text, again probably not
    a good idea.

Any ideas ?

Cheers,
           -Tristan

PS: I am inclined to commit my previous fix to size-groups to take
natural size into account as well as minimum size; if only in the 
interest of having saner/better code in place before fixing the 
above scenario...