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

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

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

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

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.

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! ;)

> 
> Regards,
>                                         Owen

---
ciaoTJ