Re: New widget proposal: GtkLiveSearch

[Xavier Claessens <xclaesse gmail com>]

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>:
>
> > Hello,
> >
> > 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.

Regards,
Xavier Claessens.