RE: PROPOSAL: GTK_WIDGET_COMPOSITE_CHILD flag

[Tim Janik <timj gtk org>]

On Mon, 24 Aug 1998, Damon Chaplin wrote:

> There's also the slight problem that foreach() in GtkNotebook only iterates
> over the pages at present, so its difficult for a GUI builder to find the
> tab labels/popup menuitems in a generic way. (In Glade I had to add special
> code to iterate over the notebook tabs as well.)

ok, i've started out on the actuall implementation of GTK_COMPOSITE_CHILD.
thing is, various internal gtk calls depend on _foreach to iterate over
all children. it is rarely used to walk only non composite children, examples
for this are show_all and hide_all. so the point remains that we need
to be able to walk over *all* existing widgets in the widget tree.
since incorporating all composite children into the _foreach calls would also
change Gtk's current API behaviour, which some programs may rely on, it is
probably not the best way to include all children into the existing _foreach
call.
also, including composite children would cause a bunch of the containers
to implement show_all and hide_all functions, to leave the composites out,
since they care for the composites anyways.
rather than implementing two new function calls (hide_all and show_all) for
all the containers that have composite children, it seems more appropriate
to let the GtkWidgetClass methods show_all and hide_all vanish, and introduce
a new class method _forall for containers, that will be used inside
of gtk to iterate over the whole tree, i.e. normal children plus composites
(e.g. needed for propagation of styles or states).
i'm not sure _forall is the best name, other possibilities would be
_foreach_internal or somesuch, but that can still be changed...

> 
> Damon
> 

---
ciaoTJ