Re: initial draw problem with gnomedruid/gtklist

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> On 18 Feb 2000, Owen Taylor wrote:

> > > > OK, I tracked this one down and I'd say it is pretty clearly a GTK+
> > > > bug, though it could be conceivably blamed on GnomeDruid.
> > > > The problem is the following code in gtkcontainer.c:
> > > > 
> > > > =====
> > > > void
> > > > gtk_container_queue_resize (GtkContainer *container)
> > > > {
> > > >   GtkContainer *resize_container;
> > > >   
> > > >   g_return_if_fail (container != NULL);
> > > >   g_return_if_fail (GTK_IS_CONTAINER (container));
> > > > 
> > > >   [...]
> > > >   
> > > >   resize_container = gtk_container_get_resize_container (container);
> > > >   
> > > >   if (resize_container)
> > > >     {
> > > >       if (GTK_WIDGET_VISIBLE (resize_container) &&
> > > > 	  (GTK_WIDGET_TOPLEVEL (resize_container) || GTK_WIDGET_DRAWABLE (resize_container)))
> > > > 	{
> > > > 
> > > >   [...]
> > > > =====
> > > > 
> > > > In the test case, list items are added just before switching to a 
> > > > new page of the druid.
> > > > 
> > > > When the items are added the above code is triggered, and the
> > > > resize_container found is the GtkScrolledWindow.
> > > > 
> > > > The GtkScrolledWindow is not mapped, since it is in is not
> > > > current, so the above code thinks it doesn't need to queue a 
> > > > resize, since one will be queued when the window is mapped.
> > > 
> > > sorry owen, *why* is the scrolle dwindow not mapped? i got parsing
> > > errors from your above sentence.
> > 
> > Sorry for the missing words. It is not mapped because the GnomeDruid only 
> > maps the current page. 
> > 
> > The notebook would have the same problem except that it queues random
> > extra size-allocates to work around its drawing bugs.
> 
> oh, i see.
> basically, gtk+ simlpy doesn't currently support unmapping/mapping out
> of the usuall widget_show/widget_hide+parent->child constrains, the
> notebook goes through some ugly hacks due to that. we may want to consider
> this for 1.3 though, e.g. by adding a toplevel like need_resize flag to
> containers in general and bind some resize logic to the widget mapping
> process. i'm pretty sure though (off head), that simply having
> 
> > > >  if (GTK_WIDGET_VISIBLE (resize_container))
> 
> in container_queue_resize() will produce malicious behaviour *somewhere*
> down the line.

As I recall it, the iterations we went through for that statement were
because we were too aggressive about not queuing resizes. The:

 GTK_WIDGET_TOPLEVEL() 

test is in there because we size allocate toplevels before map them,
so the GTK_WIDGET_DRAWABLE() test wasn't working properly. 

But the GTK_WIDGET_DRAWABLE() doesn't properly filter out widgets that
aren't visible even now, since a widget can be visible, and mapped,
and yet not appear on the screen if one of its ancestors is not mapped.

The case where we set the need_resize flag is caught by the 
GTK_WIDGET_VISIBLE() part of the condition.

I'd claim that the exact test we want here is straightforward - we
need to queue a resize if and only if the resize_container and all of
its ancestors are visible.

We don't need a need_resize for containers in general (although we
have the flag in the GtkContainer structure) because we always queue
a resize when anything other than a toplevel is shown.

Regards,
                                        Owen