II have not thought (enough) about Gtk.TreeSortable yet. When properly iterable I think sorting should (if possible) happen at the source model instead of in a decorator, but I can see the need for such a Gtk.TreeSortable of course (for non-sortable source models).

I would probably make GLib.TreeSortable an interface that can be implemented. And then have a wrapping GLib.TreeSortableWrap that implements it, and that wraps (decorates) non-sortable GLib.TreeModels by keeping a mapping of all its sorted nodes to the non-sorted nodes in the wrapped source model.

As for pixelpapst’s suggestion to try to get this in in early current versions of GLib and Gtk+: it all depends on the decision to accept the proposal to have a collection framework in GLib. If this ain’t accepted, this kind of “doing it right” ain’t possible in a practical way.

AFAIK GLib 2.90 has not even been opened, so theoretically there would be time enough to polish these interfaces a bit and get them into GLib 3.0.
Then we could also ship GTK+ with a simplified Gtk.TreeView2 (maybe call it Gtk.NodeView or something ?), and deprecate Gtk.TreeView but carry it around for the whole 3.x timeline. Gtk.TreeModel could implement the new interfaces but be supplemented over time by simpler implementations.

Your GLib.TreeIterable interface strikes me as something you would want on the concrete Iterator, not as a subclass of Iterable, because you want to iterate over the children of the currently iterated-to row. So maybe it would better be named TreeIterator.
Also, maybe get_children should return TreeIterator directly, instead of TreeIterable ? (The former would return another iterator, which should be enough; the latter would return “the node” in an Iterable form, which wouldn’t necessarily have an equivalent gobject class.)

Maybe demanding that the rows (nodes ?) returned by a GLib.TreeIterator implement a simple property interface in the spirit of your Glib.ColumnBinding would be ok ? I’m thinking something like this:

interface GLib.ColumnAccessor {
GLib.Value get_value (int column);
}

We have enough introspection to check at runtime if this interface is implemented, and skip over the row if it’s not. This check might be too costly in real-world treeviews, though.
Then again, just reusing the (overriable) GObject.get_property() class method might be completely enough. (Just do the mapping of property name to per-class property number at a higher level in Gtk.TreeView.)

@Benjamin:
agreed that the different iterator representations are the most horrible part of the API (possibly only fighting for 1st place with the whole column API).
About making ITERS_PERSIST the default: maybe a looser guarantee would be enough, where iterators gain a is_valid property, or emit a signal when the row below their butt disappears.
Then the new TreeView could still cache them all day long, and trying sane fallbacks when they invalidate.

From the TreeModel API I fuzzyly remember that at least one representation of the Iterators was designed to be stored in a fixed-size space within TreeView, probably in an array. This is not something we can easily fullfil with a simplified implement-your-own-iterator API approach, but maybe that particular design constraint is just not that important.
Iterators might have to be cloneable, though.

Sorry for my long ramblings. :-)

And that’s just the first few things I came up with. ;)

What I care about though is the API for developers and how ridiculous it is currently. I don’t want to have to care about iterators or store objects, I just want to say “here is my data, make a list” and get back to having fun!

Thanks for the post.