(In reply to comment #0)
> Since a GtkTreeModelFilter does not influence sorting in any way, it would be
> very simple to implement GtkTreeSortable with just passing through the sorting
> calls to the filtered model. Unfortunately, this only works properly if the
> filtered model implements GtkTreeSortable.

The filter model can influence sorting.  It supports ModifyFuncs that can change values in columns.  Also, I can imagine sorting functions to depend on the visible state.  These are very extreme cases which are most probably not used often -- but such corner cases need to be supported.  (You really don't even want to know what kind of things people attempt to do ;) ).

We have never implemented the GtkTreeSortable interface in the GtkTreeModelFilter, because we've mostly been thinking about getting GtkTreeModelFilter itself to do all sorting.  This would basically mean replicating a bunch of the GtkTreeModelSort source code in the filter model.  We didn't think this to be feasible, since GtkTreeModelFilter is already very complex as is.  (And also, if using GtkTreeModelSort or GtkTreeModelFilter is fast enough for your application use case, then a combination of the sort and filter models might be fast enough as well.  If it's not fast enough, you most probably want a custom model that handles all you need).

Your approach seems to be to "proxy" the sortable calls over to the child model.  This will only work if the model contents are not modified by the filter model.  I am also wondering if it is possible at all to set a sorting function written to target the filter model (since that is the model you set the sort function on) on a child model.  (If the sorting function does not make any assumptions about the kind of model it gets passed in and just uses the GtkTreeModel interface methods, there should be no problems I guess.  Unfortunately, we cannot assume that).

> So before I proceed, I'd like to know the best course of action for these
> questions:
> 
> Should GtkTreeModelFilter implement GtkTreeSortable and just ignore sorting
> calls when the filtered model doesn't implement it?
> Or should we have a GtkTreeModelFilterSortable that requires a sorted child
> model (or inserts a GtkTreeModelSort if not)?

I don't really see the point of both of these options.
 
> Should calls to gtk_tree_sortable_set_sort_func() be forwarded to the child or
> should they be ignored and setting the sort function be required on the real
> model?

If you would require to set the sort function on the child model, then the use case for the GtkTreeSortable implementation in GtkTreeModelFilter mostly goes away *apart* from passing the sorting commands from the view down to the model handling the sorting.

To me it feels like the main point is to lose model overhead by getting one of the child models (that is not connected to the view) doing the sorting, but still keep the "automatic" control of the sorting done by GtkTreeView.  For this we need adaptations to the GtkTreeSortable interface.

I see two reasons why GtkTreeModelSort is currently slow:
 1) Often it has to use slow insertion sort.
 2) For all sorting it has to do, it has to use the gtk_tree_model_get*() calls to retrieve values from the child model.  When the child model handles sorting, this is not needed.

Are there more?

We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.