After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 588250 - GtkTreeModelFilter should implement GtkTreeSortable
GtkTreeModelFilter should implement GtkTreeSortable
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.13.x
Other Linux
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2009-07-10 14:43 UTC by Benjamin Otte (Company)
Modified: 2018-02-10 03:31 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Benjamin Otte (Company) 2009-07-10 14:43:17 UTC
I've seen quite a few tree models that needed to do filtering, but wanted to do sorting, too. They usually end up doing GtkList/TreeStore => GtkTreeModelFilter => GtkTreeModelSort and set this model on their tree view. However, sorting with GtkTreeModelSort is quite a bit slower than with a tree or list store.

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.


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)?

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?
Comment 1 Kristian Rietveld 2009-07-17 21:03:31 UTC
(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?


Comment 2 Matthias Clasen 2018-02-10 03:31:53 UTC
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.