Re: Fixing the GtkTreeModel::row-deleted inconsistency

[Federico Mena Quintero <federico ximian com>]

On Wed, 2007-05-09 at 14:06 +0200, Kristian Rietveld wrote:

> In the past all GtkTreeModels used to emit the row-deleted signal *after* a
> node had been fully deleted from the internal data structures.  This means
> that it is not possible to get an iter to that node any longer.  When
> fixing up the GtkTreeModelSort and GtkTreeModelFilter long ago, it appeared
> that emitting row-deleted after deleting the node is troublesome.  These
> models implement their own reference counting (the ref_node and unref_node
> methods), and on deletion of a node some objects (GtkTreeView in
> particular) have to release their last references to the node.  For this
> they need the iterator, which is not available anymore.

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.

[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...]

  Federico