Re: gtk-container problems

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
> diff -u -p -r1.109.2.1 gtkcontainer.c
> --- gtkcontainer.c	15 Apr 2002 22:22:40 -0000
> +++ 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.

whether you want that behaviour for scrolled windows is an
orthogonal issue. i think you can savely switch them to
QUEUE_RESIZE, but don't break an existing resizing concept
(whether RESIZE_CONTAINERS other than toplevels are good
to have is another issue, but too late to change anyways
since we've committed to our API stability already).

> Additionally, the issue was raised of whether or not GtkScrolledWindows
> should remain RESIZE_CONTAINERS given that the primary motivation for
> this (preventing flicker) is gone.
> Comments?  Or should I just apply this patch to stable and HEAD (and
> possibly 1.2).

nope, switching scrolled-windows to QUEUE_RESIZE should fix your
problems instead. for 1.2, i wouldn't apply eitehr change, the resizing
algorithm for container+window is different there, as well as the
scrolled window size negotiation.

> Thanks,
> -Jonathan


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