[gtk-list] Re: reparenting containers with a window of t
- From: Patrice Fortier <Patrice Fortier aquarel fr>
- To: gtk-list redhat com
- Cc: heir aquarel fr, own aquarel fr
- Subject: [gtk-list] Re: reparenting containers with a window of t
- Date: Mon, 2 Feb 1998 17:28:05 +0100 (MET)
> > 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]