Re: initial draw problem with gnomedruid/gtklist



On 18 Feb 2000, Owen Taylor wrote:

> 
> 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.

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.

---
ciaoTJ



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