GNOME Bugzilla – Bug 739977
Don't wait for ENTER to initiate search
Last modified: 2014-12-05 03:09:51 UTC
I accidentally started reading the code surrounding GtkSearchEngine while trying to figure out bug 739651 I had to actually read through the code to figure out that search really works in the file chooser because unlike other core GNOME applications, it needs you to hit ENTER. It would be nice to remove this inconsistency.
Created attachment 290428 [details] [review] query, searchengine: Drop unused and undefined function declarations
Created attachment 290429 [details] [review] file-chooser: Don't wait for ENTER to initiate search
Comment on attachment 290429 [details] [review] file-chooser: Don't wait for ENTER to initiate search My only concern with this patch is that usually it doesn't make sense to search for anything before waiting at least 500-750ms, because people typing often don't want to find "a" but "andrew" or something like that and searching prematurely uses resources unnecessarily. We also need to be sure other backends are acceptable to this kind of change, for Tracker it's fine. Also, for Tracker, it often makes no sense to search for something < 3 characters long because they're often stop words or the criteria is too vague.
This is a good idea. Note that the ::search-changed signal that Debarshi uses here already has batching built-in - we wait for 150ms after the last keypress before firing it. We should look at adding a minimum length before starting a search, but other than that, I think this is cool.
As Matthias pointed out, search-changed has batching built in, and almost all apps are using it. Nautilus has its own timeout mechanism because it predates search-changed. I filed bug 740000 for that. Regarding checking for a minimum length, I don't see anything doing that at the moment. gnome-shell happily hands over a single character to its search providers if the user did not type any further; gnome-control-center, gnome-tweak-tool, gnome-documents and nautilus also does not have any minimum length checking built in. This behaviour has existed for a while, so I can only guess that it is not a big problem. I mean, we are already batching. So, if the user continues to type then the first few characters won't trigger a search. On the other hand, if she types one character and does not do anything after that, then probably she really wants to search for that single character. CCing Cosimo for his comments.
Attachment 290429 [details] pushed as 8718e92 - file-chooser: Don't wait for ENTER to initiate search