Re: Fixing the GtkTreeModel::row-deleted inconsistency

[Kristian Rietveld <kris imendio com>]

On Wed, May 09, 2007 at 03:43:20PM -0500, Federico Mena Quintero wrote:
> Is there a description of when/how a model should implement
> ref/unref_node?  I recall asking this to JRB many times, but the
> semantics were never completely clear to me.

There are no clear rules for this, actually.  Most simple models don't
have a real use for this.  The filter and sort models both use this
mechanism to keep track of which levels to cache and monitor.  Models
which reference external objects might want to use it.  A node is
referenced when it is visible.  In the rule all expanded nodes count as
visible; all nodes which are in GtkTreeView's internal rbtree are
referenced.

How {ref,unref}_node are implemented really depends on the model and
what it tries to achieve AFAIK.


> [The row_deleted signal always comes from the model, which means "this
> row is really gone".  Why would callers later need to unref that
> row-which-is-already-gone?  The model will have freed the row's
> resources by then...]

It is indeed documented as working as such.  There are plausible cases
for a model user to access a node in its row-deleted callback.  You
might want to write to the object stored in the row during deletion, or
see the other case mentioned in this thread -- I'm sure there are many
more use cases.

It is good that you bring this question up though, since it made me
think again about these changes.  I actually just found a small note in
the documentation that deleted rows are not supposed to be unreffed --
something which was already convoluted in the code.  Now I vaguely
remember hearing about this before and that there are cases where not
unreffing deleted nodes caused trouble (or something similar).  I will
hash this out first and try to find those testcases before further
exploiting making modifications to the row-deleted sementics.


thanks,

-kris.