Actually that's already covered by bug 750832.

*** This bug has been marked as a duplicate of bug 750832 ***

Bug #750832 was marked as resolved because there's a preference in Nautilus to recursively search always, for local files only, or never. *This* bug asks for a checkbox or some other way to toggle recursive search *for the current active search*.

I agree that such a feature would be very nice to have. Toggling recursive search would also probably be a good compromise for the many people (based on Bug 775297 and its duplicates, and others like it) who still miss Nautilus's "type ahead" to only *select* a file in the current working directory.

Alexandre, in Bug #750832 you seemed to agree that this thread is sufficiently different and could be reopened. Can we reopen it?

This feature request was originally opened against Nautilus, but I think it would be helpful if it were applied to the GTK file picker too.

Can we reopen this issue? Again, there's still not a super convenient way to toggle recursive search in Nautilus, and no way to toggle it at all in the GTK file picker.

Hello, thanks for your interest.

-> Can we reopen this issue?

The initial description of bug 750832 has a link to an early design mockup which included a recursive search toggle in the search popover, as suggested here. Then, as stated in comment 6 of the same bug, the resolution was to move the toggle to the Preferences dialog.

Given that this suggestion has already been carefully considered at that time, there is no need to reopen for the sake of reopening.

This design can be revisited depending on, for instance, new information about use cases, when the recursive search preference needs to be frequently toggled and why.

-> Again, there's still not a super convenient way to toggle recursive search in Nautilus,

Can you elaborate why the option in Preferences is not convenient? Do you need to frequently change your preference? Why is none of the 3 options ("Never", "Local only", and "Always") adequate for your needs?

> and no way to toggle it at all in the GTK file picker.

The GtkFileChooser issue is tracked at https://gitlab.gnome.org/GNOME/gtk/issues/839

You may want to subscribe that issue. Please bear in mind that it is a very long issue to read, which makes it already hard enough to work on. Comment only if adding something not stated by earlier comments.

Sorry for the delayed response.

> Can you elaborate why the option in Preferences is not convenient? Do you need to frequently change your preference? Why is none of the 3 options ... adequate for your needs?

The option in Nautilus preferences seems to me like it's trying to allow users to optimize search performance for their particular computer. Recursive search is slower, of course, especially if it's happening over the network instead of on a local file system. So, it makes sense to let the user choose the option that suits the speed of their local machine and/or their local network.

However, the idea for me, and I think the idea behind the original feature request, wasn't about optimizing search speed, but rather to make it easier to switch between *types of search tasks*:


1. Recursive search is useful when you only partly remember where a file is. "It's somewhere under ~/Documents/..."

2. Nonrecursive search is useful when you know exactly where the file is -- though not necessarily its full name. "Okay, here in my Funny Pictures folder, there should be a gif called cute-cat-something-something..."

3. Nonrecursive search is also useful as a substitute for the removed feature that I think was called "type ahead" -- which jumped to the first matching file rather than actually filtering the contents of the current directory. "Type ahead" was a handy way to navigate the file tree using just your keyboard, but as I recall was limited by requiring fairly exactly filename matches, and then again it only selected the first match. Nonrecursive search can accomplish the same thing but is much more flexible.


Currently, if I want to switch from doing one type of search to another, I have to move my mouse to the top bar, click on Files > Preferences, click on the Search & Preview tab, and then click on the correct option, and then close preferences before I can try my search again. The original feature request was to add a checkbox or something to the pop-down search box. That's 4 clicks and a lot more mouse movement vs 1 click. (And now that I think about it, I guess I would add a request for a keyboard shortcut to toggle recursive search, if this ever gets implemented, since being friendly to keyboard navigation is sorta the whole point of this request.)

So no, the current implementation is not terribly convenient; the options we have in the preferences dialog make more sense for (semi)permanent settings related to performance factors like disk, CPU, and network speeds, which likely won't change very often. You wouldn't expect to have to change an option in Nautilus preferences to cut vs copy a file, right? I don't think it should be necessary to change application configurations just to switch between different tasks.

I hope it's a bit clearer now. Does this make sense?

And thanks for your time.

Yes. That was very helpful, thank you for the mindful details.

That clarifies that the performance-related search recursivity preferences are convenient for that purpose as it is and doesn't need to be changed.

So, the requested toggle is not about search performance, but about filtering out results from  subfolders when looking specofically for files in current folder.


The current plan is to make such a filter without the need for a toggle, by making a clear visual separation between the "From this folder" group and the "From subfolders group", so that you can see at  a glance which is which, and whether no match was found in he current folder. Do you think can obviate the need for a filter in your usage?

> ...Do you think can obviate the need for a filter in your usage?

That all sounded good until that last sentence, which I'm unsure about.

I have no strong opinions about what the implemented design should look like, so the checkbox isn't necessary. If recursive and nonrecursive search are separate tabs or dropdown menu itmes in the search box, or separate search boxes, or whatever, that could be fine too. As long as there's a simple way to do either a recursive or nonrecursive search as needed.

In the last message I wrote "obviate the need for a filter" but I meant to write "obviate the need for a toggle".

Allow me to explain better.

The non-recursive search is a subset of recursive search. In other words, if I am looking for a file in the current folder, I don't need to disable recursive search:

Recursive search results = current folder matches + subfolders matches

Files from current folder are quickly found and always sorted above everything else, but there are a few shortcomings with the current UI implementation. There is no clear separation between the 2 sections of results, and no indication when no result from current folder was found.

Which other shortcomings do you find in the current presentation of recursive search results? 

It is important for us to understand why people feel the need to toggle recursive search frequently when hardware/network performance is not the issue.

A toggle comes with its own shortcomings. It requires you to think about it every time you search: "did I leave recursive search on or off the last time? Do I want to toggle it for this search?"

So, I think we can do better if we provide a presentation of results that addresses your concerns, such that you don't need to care if search is recursive or not. It should "just work".

We don't have a design mockup yet. Progress will be tracked in the following issue when it happens https://gitlab.gnome.org/GNOME/nautilus/issues/247

Oh, so I guess the idea is that recursive search would always be on, then? And the search results are divided into sections.

I'm thinking of an example website served by Apache httpd. You may know there can only be one .htaccess file in the current directory, but there could be many in the subdirectories.

So, I still kinda like the idea of toggling recursive search, because seeing *every* .htaccess file adds a lot of noise if you don't need it... but if the UI could clearly separate the "current folder results" from the "subfolder results" then I guess that's probably good too. And I can see how not needing to think about the type of search you need to do could be helpful.

Thanks.

Yes, that's the rough idea. You can follow the progress, when it happens, by subscribing to https://gitlab.gnome.org/GNOME/nautilus/issues/247.