rethinking GtkTreeModelSort

[Havoc Pennington <hp redhat com>]

Hi,

I think we should rethink GtkTreeModelSort as an approach to tree
sorting. As we know, it has the following disadvantages:
  - it's not especially efficient; by adding the 
    cheesy GTK_TREE_MODEL_ITERS_PERSIST flag we made it better, but 
    still not great
  - it chews RAM; you have to keep the tree of persistent iters in 
    addition to the real model
  - it introduces the complicated and confusing ITERS_PERSIST flag
  - it limits how models can be implemented, and limits our ability 
    to warn about bad iterators

So, why not give up on this, and simply add a
set_sort_column(GtkTreeModel *model, gint column) virtual function to
GtkTreeModel. I guess the objection here is that it's less convenient
to use; I don't think it really is. We would go ahead and implement it
for the standard models, which 90% of trees will use. For other trees,
any sane language has sort functions for common data structures, so
typically the implementation of this function would be a simple
qsort() or g_slist_sort() in C, or a sort() in C++, etc. I would
expect the function to typically require only a few lines to
implement. It's slightly more work to honor the sort column in the
insert/append/prepend/etc. implementation, but shouldn't be rocket
science. This is CS 101 stuff, and to write a custom model you already
have to understand GObject, so you should be able to keep a list
sorted.

For models where sorting isn't desired, people can just ignore the
sort column.

Also, this lets us automatically wire up the
clicking-on-column-sorts-it stuff, with TreeModelSort users have to
manually set up a callback on column clicked which calls
set_sort_column. So stuff will Just Work with the standard GTK models
(ListStore and TreeStore). For that matter you could even add a
column_is_sortable virtual method that lets TreeView automatically
decide whether to make each column header clickable.

Anyhow, it seems to me that a set_sort_column() virtual method on
GtkTreeModel is arguably just as convenient in many cases, is just as
generic, simplifies the API, and results in faster and less
memory-hungry code.

Am I missing any important issues?

Havoc