Re: reparenting containers with a window of their own

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

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.

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

> 
> Regards,
>                                         Owen

---
ciaoTJ