Re: [gtk-list] a parent's window (was: Re: [patch] gtkviewport design bug.)

[Owen Taylor <owt1 cornell edu>]

Tim Janik <Tim.Janik@Hamburg.Netsurf.DE> writes:

> On 18 Jan 1998, Owen Taylor wrote:
> 
> > 
> > Tim Janik <Tim.Janik@Hamburg.Netsurf.DE> writes:
> > 
> > > On Sat, 17 Jan 1998, Jay Painter wrote:
> > > 
> > > > I wasn't able to find your patch, so I don't know exactly what it does,
> > > > but I came up with probably one of the shortest solutions to this problem,
> > > > and it seems to be pretty bullet-proof.
> > 
> > [ ... ]
> > 
> > 
> > > > This is a good technique to keep in mind if you are composing a new widget
> > > > with multiple windows of it's own, and you want to put widgets into those
> > > > windows which are not widget->window.
> > > 
> > > hm,. what is about NO_WINDOW widgets?
> > 
> > True. This only works if you know that your children have windows.
> > The complete code for reparenting other widgets is in
> > gtk_widget_reparent, but duplicating it is ugly.
> > 
> > Also, thinking about reparenting, the existing Viewport won't
> > reparent properly because widget->window doesn't contain the
> > widgets other windows. Finally a _good_ reason for making 
> > Patrice's change! :-)
> > 
> > With that in mind, I implemented it properly. I'll describe
> > what I did separately.
> 
> hm, i didn't find the description in my personal archives,
> but i apologize if i just didn't look deep enough... ;)

I did send it... But your desription is correct.
 
> anyway, what these patches currently does is, the
> gtk_widget_get_parent_window function either returnes a special hint
> that has been set by the parent previously (via
> gtk_widget_set_parent_window), or widget->parent->window.
> 
> now a container does a
> gtk_widget_set_parent_window within the container_add function if so
> needed (this is if the parent window from a child's viewpoint isn't
> widget->parent->window).
> now this caused some minor problems in the widget reparenting code,
> when i applied marius patch (some of which are actually not resolved yet,
> which is why i moved the thread about
> Subject: Re: reparenting containers with a window of their own
> to this list.
> from a conceptual point of view, why didn't you just add a
> GdkWindow (*children_window) (GtkContainer *c, GtkWIdget *child);
> function in the _GtkContainerClass structure, that will
> be called by gtk_container_children_window (GtkContainer *container,
>                                             GtkWIdget    *widget)
> and returns the appropriate parent window for a child (this could
> then even depend on the child's type or on the child's flags) or
> just returns GTK_WIDGET (container)->window if
> GtkContainerClass.children_window == NULL?
> (long question that one ;)

Because it seemed like the more complicated solution. It meant
adding another signal; and more importantly the container widget
has to check when it gets the chil(ren?)_window signal which
child it is in order to determine the proper child window.

And it still doesn't buy anything in terms of reparenting because
the child still has to be gtk_container_added to the parent before
the parent can determine the proper child window. (It can _guess_
but in general it can't tell - a widget could plausibly have
children in multiple windows!)

> this approach seems to be far more flexible, folowes the
> "container" is a <parent> of a "widget" (child) idea and wold even be
> a little faster, because we avoid the hash table lookups for object_data.

I don't see it as far more flexible. Or more flexible at all
really, though I suppose you could extend it to the case 
widget=NULL => give me your best guess as to what window
a child will be added to...

> be called by gtk_container_children_window (GtkContainer *container,
>                                             GtkWIdget    *widget)

If that was a typo and it doesn't take the widget argument, as in
your example below, than it is _less flexible_.

It might be a tiny bit faster.

> owen, i'm seriously considering the reimplementation of this
> thing, because one thing that isn't done correctly and consistent
> throughout the toolkit so far is the (un-)realize portion of NO_WINDOW
> widgets, i.e.:
> 
> ....._realize()
> {
>   widget->window = gtk_container_children_window (GTK_CONTAINER (widget->parent));
>   gdk_window_ref (widget->window);
>   ...
> }
> ....._unrealize()
> {
>   gdk_window_unref (widget->window);
>   widget->window = NULL;
>   ...
> }
> 
> 
> so please comment on this! ;)

Does it really make any difference as to (un)realizing? It seems
like just a difference of how the parent window is obtained.
of the four lines of code above, only one is different currently...

We really need to start writing up some internal docs on the
widget lifecycle in any case.

If you really think it is better, I won't object if you want
to go ahead and implement it, but I'm not too convinced that
it is worth it. (And reparent _is_ working correctly now...)

Regards,
                                        Owen