GtkTreeModelSort thoughts

[Jonathan Blandford <jrb redhat com>]

[ This is a quick brain dump of issues regarding GtkTreeModelSort.  It's
  being posted mostly for posterity's sake.  However, comments on it
  are appreciated as always. ]

Currently GtkTreeModelSort has a problem of knowing when and where to
cache information.  It is implemented as a tree implemented by GArrays,
where levels are built on demand.  The advantage of this is that we
don't wrap the entire child-model (which could be quite extensive in the
case of a file system model).  The problem is knowing how long to keep
each row around for.

The GtkTreeModel has a ref_node/unref_node operation on it.  This is
used primarily by the GtkTreeView and GtkTreeRowReference[1] objects
just so the GtkTreeModelSort can actually know which rows to cache.  The
problem comes when a programmer tries to access a row that isn't
actually on the model.

It seems like it would complicate an already complicated API beyond
usefulness if we required the user to explicitly ref the node and all of
it's parents -- and then unref them when done -- just to use an iter.  I
like the current method of just doing gtk_tree_model_path_to_iter,
getting values, and then discarding the iter when done.  This has the
potential side effect of rows with a ref count of 0 in the
GtkTreeModelSort.

To work around this, I think we need to clear the cache of zero-ref rows
every time the stamp on the iter changes (ie, a row is inserted,
deleted, or changes etc.)  Unfortunately, there is a pathological case
of a large, static model being wrapped.  We could add a cache cleaning
method to the model (gtk_tree_model_sort_blow_chunks?!?? :-), but I
think this is probably an unlikely occurrence.

Another aspect of this code is that you won't get row signals on the
sort model on rows that aren't reffed.  I don't think this is a problem,
but it may confuse people.

Thanks,
-Jonathan

[1] Bug #61676