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 744205 - Recursive search is unusable
Recursive search is unusable
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2015-02-10 01:24 UTC by Xavier Claessens
Modified: 2015-06-01 07:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Xavier Claessens 2015-02-10 01:24:52 UTC
With GTK master the file chooser now does recursive search when type ahead. That makes thousands of matches and makes navigating through folders impossible. It's also slow when having big file hierarchy (like having tones of git clones).

I think a sane default is to lookup only in the current directory, and have optional recursive search if pressing ctr+f.

Note that nautilus does the same mistake, IMO.
Comment 1 Matthias Clasen 2015-02-10 12:05:13 UTC
if your git clones end up in tracker, its your own fault, I might say...
Comment 2 Xavier Claessens 2015-02-10 14:27:14 UTC
I don't have tracker running at all, it's not installed on ubuntu, I don't need a process that slowdown every single I/O.
Comment 3 Xavier Claessens 2015-02-10 14:28:23 UTC
Also it's not the point. Put aside the fact that recursive search is slow, it's also totally unusable to browse your file hierarchy.
Comment 4 Matthias Clasen 2015-02-10 19:26:42 UTC
Sure, if you want to browse your file hierarchy, browse it. If you want to search for a file, use search.

Not running an indexer and complaining about search being slow seems to be a bit disingenuous.
Comment 5 Xavier Claessens 2015-02-10 21:09:02 UTC
(In reply to Matthias Clasen from comment #4)
> Sure, if you want to browse your file hierarchy, browse it. If you want to
> search for a file, use search.

Yes, type ahead was and should be for browsing, and ctr+f should be for searching. Or have an option to flip them maybe?

> Not running an indexer and complaining about search being slow seems to be a
> bit disingenuous.

Basically what you're saying is "don't index your git clones" then "if you don't index your git clones don't complain it's slow". So what am I supposed to do? "Sorry having lots of files is not something we support any more"?
Comment 6 Matthias Clasen 2015-05-01 15:59:12 UTC
work in bug 746916 is relevant
Comment 7 Matthias Clasen 2015-05-01 20:36:31 UTC
we're now doing the same thing as nautilus: combine tracker results with crawling, and showing results from the current directory first
Comment 8 Milan Crha 2015-06-01 07:49:27 UTC
(In reply to Matthias Clasen from comment #7)
> we're now doing the same thing as nautilus: combine tracker results with
> crawling, and showing results from the current directory first

Does this apply to the Search sidebar section only, or to the quick search (as you call it 'type-ahead search') too? If the later, then I agree with Xavier, that's a nightmare in nautilus, why to add it to the core Gtk+ too? I hope it can be disabled (and *is* disabled by default). Do not try to be smart. If I have selected a folder, I want to "quick search" *only in that one folder*. That's why it's "quick search", not "waste-all-my-free-resources search".

As an example, try to quick search in the file system root. I even cannot imagine the Gtk+ would try to search in the whole disk hierarchy with all the mount points I have when I only want to position *quicker* to the right item in the *already populated* list of the directory content I've selected.