Re: New widget proposal: GtkLiveSearch

Le 14/06/10 10:27, Christian Dywan a écrit :
Am Sat, 12 Jun 2010 19:30:52 +0200
schrieb Xavier Claessens<xclaesse gmail com>:


I've been working on the HildonLiveSearch widget you can see on N900.
This is the entry you see when typing on the keyboard to filter your
contact list for example.

Felix Kaser and I ported that widget to Empathy's main window. The
code is in git master[1]. I would like to propose that widget to
become GtkLiveSearch[2].

So EmpathyLiveSearch right now seems to be

  smart matching function + standalone inline search

Regarding the smart matching, I think it is a bad idea to hardcode a
particular algorithm with no way to override it. Rather it should be a
function that can be used. Maybe it is also useful for, say, entry
completion, that way?

You are not forced to use the build-in match function of course. You have that method:

gboolean empathy_live_search_match (EmpathyLiveSearch *self, const gchar *string);

So when you are refiltering your treeview (or custom widget) you could use that API has helper if you want. If you want your own matching algorithm, just take the current text inside the entry and do the match you want, using that API:

const gchar *empathy_live_search_get_text (EmpathyLiveSearch *self);

And as for the standalone inline search, I would personally be hesitant
as long as the only real user is a tree view. New API for the same
feature doesn't strike me as attractive in sight of GTK+ 3.0 with its
many valid deprecations.
I would suggest if somebody has a non-tree view use case it makes a lot
more sense to consider it. Also to confirm that it actually is
convenient to use with other widgets.

I just went through the desktop, and I see for example:

1) gnome-control-center has very similar feature on a non-treeview. You can see there that the matching algo is dumb. Searching "ser" is matching "User and groups". And it even match it when running in French where it is "Utilisateurs et groupes" which does not contain the "ser" substring. The matching algorithm I made in EmpathyLiveSearch only check word prefix which is what you would expect IMO.

To be fair, in that example the live search entry is always shown, unlike EmpathyLiveSearch which gets shown/hidden automatically if there is text typed on it. maybe that could be made optional with a boolean property on EmpathyLiveSearch.

2) Nautilus could use that to search a folder too, it would be so much more powerful than the current treeview-like search bar. In that example, I see for example that if you have a file "foo-bar.png" and you search "bar", then it is not matched. EmpathyLiveSearch's algo split words on non-alphanum characters and search in the prefix of each word. Also *filtering* on the search is better than *selecting* IMO. You can see clearly the results. But that's not EmpathyLiveSearch's job anyway, any app do as they want.

3) I just had the idea that it could be used for GtkComboBox to search an item in its dropdown menu. That's a feature I really miss in epiphany-webkit compared to firefox... not sure yet how that could be presented in the UI though. Probably in that case we don't need to display an entry at all.

Hmm... probably 1 and 2 are the general use-case for GtkIconView.

Xavier Claessens.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]