Re: initial draw problem with gnomedruid/gtklist
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- cc: Gtk+ Developers <gtk-devel-list redhat com>
- Subject: Re: initial draw problem with gnomedruid/gtklist
- Date: Fri, 18 Feb 2000 18:53:56 +0100 (CET)
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]