Re: initial draw problem with gnomedruid/gtklist

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> On 17 Feb 2000, Owen Taylor wrote:
> 
> > 
> > NotZed <notzed@helixcode.com> writes:
> > 
> > > Hi guys,
> > > 
> > > The attached program below demonstrates a problem i'm
> > > having with GnomeDruid, Havoc suggested I post here.
> > > 
> > > Basically the problem is that some things I have inside of
> > > viewported'd scrolled windows dont seem to render, until
> > > you resize the window, and then ones that continue to
> > > render as i switch pages dont update their contents if the
> > > contents change during the page setup.
> > > 
> > > Anywya, the program is below, and the behaviour is
> > > self-explanatory.
> > 
> > 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.
 
> > But the scrolled window is visible, and all its parents are visible,
> > and no resize is queued when it is mapped. For this reason the newly
> > added list items never get size allocated.
> > 
> > I think the above conditional is just completely bogus. It could
> 
> i definitely don't, that code portion has been changed quite a couple
> of times to figure the correct condition. basically no resizes should
> be queued on not mapped containrs (constraint), with the exception that
> we want to keep a flag for resize needs on toplevels. but you probably
> already know that, and maybe i see your point after i understand your
> above sentence.
>
> > be:
> > 
> >  if (GTK_WIDGET_VISIBLE (resize_container))
> > 
> > Or, if you wanted to be more precise, you could define a function
> > that checked if a widget and all its parents are visible and 
> > replace the GTK_WIDGET_DRAWABLE() in the above with that. But I don't
> > think the win in efficiency from doing so is very large.