Re: gtk-container problems

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 15 May 2002, Jonathan Blandford wrote:
> 
> > Hi,
> > 
> > I found an subtle bug in GtkContainer, when you have a RESIZE_CONTAINER.
> > The problem appears to be that RESIZE_CONTAINERS are not propagating
> > size changes in their children up.  This normally isn't noticed, because
> > scrolled windows don't normally have their requisition change, but can
> > be triggered by setting one of the scrollbars of a scrolled_window to be
> > POLICY_NONE.  Owen helped me track this down, and we came up with the
> > following patch.
> > 
> > Index: gtkcontainer.c
> > ===================================================================
> > RCS file: /cvs/gnome/gtk+/gtk/gtkcontainer.c,v
> > retrieving revision 1.109.2.1
> > diff -u -p -r1.109.2.1 gtkcontainer.c
> > --- gtkcontainer.c	15 Apr 2002 22:22:40 -0000	1.109.2.1
> > +++ gtkcontainer.c	15 May 2002 20:46:54 -0000
> > @@ -1088,11 +1088,7 @@ gtk_container_real_check_resize (GtkCont
> >    if (requisition.width > widget->allocation.width ||
> >        requisition.height > widget->allocation.height)
> >      {
> > -      if (GTK_IS_RESIZE_CONTAINER (container))
> > -	gtk_widget_size_allocate (GTK_WIDGET (container),
> > -				  &GTK_WIDGET (container)->allocation);
> > -      else
> > -	gtk_widget_queue_resize (widget);
> > +      gtk_widget_queue_resize (widget);
> >      }
> >    else
> >      {
> 
> this basically breaks the concept of resize containers
> alltogether, i.e. that they don't propagate the changes
> up. that's an API change that should not happen at this point.

I'm pretty sure that wasn't the behavior we intended originally,
though 4 years later or whatever, it's a bit hard to remember;
scrolled windows were our principal use case for non-toplevel 
resize containers, and if they don't work properly....

But in any case, it's fundementally broken for a widget to
change it's requisition and not notify its parent; just
because we don't tell our parent doesn't mean that the change
will have no effect; it just means that the change will
have an effect at some unpredictable later time.

In GTK+-1.2, this would have shown up as 

 "if the user resizes the toplevel, then the minimum size
  of the toplevel will be updated, and the toplevel will
  suddenly jump to a new larger size"

In GTK+-2.0, it will be a bit different. Resizing the toplevel will
have no effect because the NEED_REQUEST flag will never be set on the
ancestors of the resize container. But if you, say, change your
current theme, or a sibling widget of the widget changes size, then
suddenly the toplevel will jump to a new size.

The only case where the current behavior isn't entirely broken
is when the size of the resize widget doesn't depend on the
size of the its children. But in that case, a resize queued
on a descendent won't typically cause the condition:

    if (requisition.width > widget->allocation.width ||
        requisition.height > widget->allocation.height)
     
So the proposed change will have no effect.

Of course, the change above doesn't really fix the problem ...
you still get hysteresis when the child gets smaller; but it
makes things somewhat less broken. 

Regards,
                                        Owen