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



> > On Sat, 31 Jan 1998, Owen Taylor wrote:
> > > 
> > > 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)

Is this a joke?

You mean that when you want to reparent a widget, you unmap it,
then unrealize it (destroy it), rerealize it (create it) with
an other parent, and then remap it!???!
And you'd like to do that trick recursively???
I can't even believe that *you* wrote this!

There are a REPARENT X event and an XReparentWindow function for
that.
Why don't you use it?

Why do you send dozens of X events (un/map un/realize...), allocate/
deallocate memory for the windows and widgets when all you have to
do is send 1 event, calling XReparentWindow (which tells X to do
the job)?

<...>

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

Noooooo!

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

I wanna die...


Patrice.




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