Re: [gtk-list] Re: reparenting containers with a window of their own

[Owen Taylor <owt1 cornell edu>]

> i've moved this discussion to gtk-list cause i think there might be
> slightly more input from people on this topic.
> 
> On Sat, 31 Jan 1998, Owen Taylor wrote:
> 
> > OK, I think see _what's_ happening.
> > 
> > First, serious problems are happening with the current implementation
> > of gtk_widget_reparent() because g
> > 
> >   if (widget->parent != new_parent)
> >     {
> >       gtk_widget_ref (widget);
> >       gtk_container_remove (GTK_CONTAINER (widget->parent), widget);
> >       gtk_container_add (GTK_CONTAINER (new_parent), widget);
> >       gtk_widget_unref (widget);
> >       
> >   [ lots more stuff ]
> > 
> > Because gtk_container_remove (now?) unrealizes the removed widget.
> > Which makes sense (in a normal use of gtk_container_remove) _but_
> > means that we might as well stop here. If the _remove and _add
> > work correctly, the GdkWindow has been destroyed and added. And
> > there is no point in preceding on to gdk_window_reparent.
> > 
> > The problems occur because gtk_widget_unrealize doesn't propagate
> > on to the children of the widget. This is bad because once a 
> > when a window is destroyed, it destroys the child windows, but
> > the child widgets still have references to them. (They'll
> > eventually get DESTROY events, but not until after the damage
> > is done)
> > 
> > The quick solution, which may help in other cases is to then
> > modify gdk_widget_realize() to unrealize the children (before
>          ^^^^^^^^^^^^^^^^^^^  you mean gtk_widget_unrealize here?
> > it unrealizes the main widget)
> 
> the order should be reversed, first unrealize the parent window
> then the ones of the children. this is actually just a matter of
> how the signal is propagated, but you wouldn't want to see each
> widget of a list disappearing one by one and then the parent
> (this has been the reason why peter didn't propagate an unrealize
> event through the children once a parent got destroyed/unrealized
> and why gtk_widget_show (window) is the _last_ call upon window
> creation.

OK, I think you are right about this. I was worried that it
would cause problems because the child windows would be destroyed
by X when their parent was destroyed, but not marked as destroyed.
But looking into gdk_window_destroy, I see that GDK already
takes care of this.

> > This doesn't get us the gdk_window reparent behavior back, though.
> > If we want that, my guess is that the best way to 
> > do things is to change the windows first, then check in
> > gtk_widget_unparent/ set_parent to see if the widget->window is
> > what we expect. If it isn't then don't do the unrealize/realize.
> > That is pretty gross though, and just an optimization, so
> > maybe we should leave it out for now.
> 
> well, we should really get an idea about wether we want
> gtk_widget_reparent() to either
> unrealize all widgets and then rerealize them with the new parent
> or
> we do the optimization of a gdk_window_reparent-ing.

With the expense of one flag, I've gotten so it does the
gtk_widget_reparenting (or just adjusting widget->window for
NO_WINDOW widgets) when possible, and realizes/unrealizes
otherwise.

                                        Owen