Re: _foreach vs _forall (RE: PROPOSAL: GTK_WIDGET_COMPOSITE_CHILD flag)

Tim Janik <> writes:

> i've continued to work on this (got distracted by some personall issues),
> and the result is this:


errm, can I take this opportunity to introduce the `reference tracing'
feature I want to have?

Basically, I want to have a way to enumerate absolutely all GtkObjects
that are referenced by a certain other GtkObject, that is all
GtkObjects that the other GtkObject has called gtk_object_ref for.

This is very useful for language bindings that have a tracing garbage
collector (like Guile).  With this reference tracing function, the
garbage collector can detect cycles of unused objects.

Tracing the references is close to enumerating all children (including
the internals), but it should include still more references, like from
a Tooltips object to the widgets that it has tips for (iff tooltips
have such references). 

I think the INCLUDE_INTERNALS argument of the forall method could be
extended to be a enum with members GTK_INCLUDE_USER,
GTK_INCLUDE_INTERNAL, GTK_INCLUDE_REFS or something.  It is ok to miss
some of these references, so treating GTK_INCLUDE_REFS as identical to
GTK_INCLUDE_INTERNAL would be allowed, if that makes the conversion
more convenient.

The problem is that this reference tracing is not restricted to
containers, so the forall method would have to be added to GtkObject

What do you think?  Can forall take the additional burden or should I
go for a different class method all together?

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