Re: Fixing the GtkTreeModel::row-deleted inconsistency

[Fontana Nicola <ntd users sourceforge net>]

On Wednesday 09 May 2007 22:43, Federico Mena Quintero wrote:
> [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...]

A while ago I hit the same problem.
Suppose you are maintaining a summary field of a model (the SUM() of a column, 
for instance): you need to catch the "row-changed", "row-inserted" 
and "row-deleted" signals of your GtkTreeModel implementation. But in this 
case there's no way to access a valid row in the "row-deleted" callback.

Thank to a Vivien Malerba's suggestion, I had to wrap the data to be 
summarized in a G_TYPE_BOXED derived type and to use its GBoxedFreeFunc to 
catch the deletion.

No needs to unref, but having a still valid row in the "row-deleted" callback 
can save some trouble (at least in this case).

-- Nicola