Suggestion: use a timeout-based search activation to prevent the FileChooser from spamming the desktop search backend

So, I know this may sound like a bit of a hack (theoretically speaking) to introduce artificial delays into searching, but I think it's absolutely good practice "in practice"—in the imperfect world where search engines (like Tracker, and whatever the fallback is when it's absent on a system) tend to choke (or at least burn the CPU and grind the disks) when you type at 8 characters per second (100 words per minute)—to use a timeout-style search trigger whose timer resets on every character being typed, and then waits for the timeout to happen (i.e. no keyboard activity for roughly half a second) before triggering search. Your backend will suffer much less, there will be less UI glitches and jankiness, it will feel more "responsive", and as a result user experience will be better.

This is the same idea as what I presented in nautilus#1731 (closed), and I've proven that approach to work in various other applications; see that ticket for details, and links to example implementations.

In the case of the file chooser, I think that such an algorithm would stand the test of time no matter what backend or UI it serves, for as long as you continue to use search-as-you-type in the FileChooser (I doubt that search-as-you-type would disappear in the issue 1239 redesign project).

In theory this might hide some race-type problems under the rug (such as issue #692, which should still be addressed of course), but I suspect the improvement is good to have under any circumstances anyway, race or not.

I am filing this ticket here simply to suggest to whoever may be looking at this (established maintainers, new contributors, etc.) to consider this rather simple hack. The implementation in apps like GTG was rather trivial from what I've seen, so perhaps one of you will be interested in doing this in GTK too. I'm envisioning this first and foremost for the FileChooser's internal search feature, but maybe someone looking at this would consider it worthwhile to include that sort of functionality in GtkSearchBar too for other apps using that (but that's probably more complicated, because then you might be touching API, I suppose).

Thank you for considering this!