GNOME Bugzilla – Bug 710204
GListModel should have more advanced filtering helper
Last modified: 2018-05-24 15:45:01 UTC
GLib now gained advanced matching function helpers (see bug #709753): g_str_tokenize_and_fold() g_str_match_string() I think GtkListBox should make good use of them to help filtering the list when user search terms. We could add: void gtk_list_box_row_add_search_text(GtkListBoxRow *row, const gchar *text, const gchar *translit_locale); void gtk_list_box_set_filter_text(GtkListBox *list, const gchar *text, gboolean accept_alternates); The internal function gtk_list_box_apply_filter() could then do filtering based on the text, similar than what g_str_match_string() does but with pre-computed tokens.
I'd rather leave that up to the user of the listbox, tbh
Created attachment 257377 [details] [review] GtkListsBox: Add filter on text helper
Created attachment 257378 [details] [review] Improve search-bar example to demonstrate GtkListBox filtering
(In reply to comment #1) > I'd rather leave that up to the user of the listbox, tbh IMO it is common and non trivial to get right enough that we want the toolkit to handle it for apps. Ryan agreed with me on IRC.
Note that my attached patches are not ready yet, they are missing doc at least. But I would like a consensus before finishing the work.
Hm, actually I've been thinking a bit more about this and I'm not sure about one thing: I hope that GtkListBox will get a model behind it at some point to create GtkListBoxRow widgets on the flight when scrolling to avoid performance problems when creating a huge list (lots of people have 5000+ contacts!). In that case I'm not sure how the filtering should work... Should we be filtering on the model before creating the rows, or should the view ask more rows until it gets visible rows? So maybe this bug is premature and should wait for solutions for big lists first.
Review of attachment 257377 [details] [review]: ::: gtk/gtklistbox.c @@ +104,3 @@ + + /* HashSet<strv> */ + GHashTable *tokens; a hashtable _per row_? this seems wrong... and when you use it, you just iterate... if you do indexing at all, it should be on the level of the entire list. for the rows, just store a gchar**. you can either do a gchar**-vs-gchar** test per-row or build an index for the entire list.
Actually that comment is a lie, it's a GHashTable<string> not strv. It's a hashtable used as a set to make it easy to add more tokens. My use case for that is in empathy a row can be matched for multiple strings: email, fullname, etc... so each row has a contact and I can do: gtk_list_box_row_add_search_text (row, "xclaesse@gmail.com"); gtk_list_box_row_add_search_text (row, "Xavier Claessens"); And the row will match when searching for "xclaesse" as well as "xavier". I can implement that with a GPtrArray<string> of course, but then adding tokens is more boring :p
I think everybody wants filtering to work with models nowadays
(In reply to Matthias Clasen from comment #9) > I think everybody wants filtering to work with models nowadays Doesn't mean the bug is WONTFIX, just that it needs to be reassigned. It should be done on GListModel now indeed.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/765.