GNOME Bugzilla – Bug 687002
Trouble with Recursive Search
Last modified: 2014-02-10 17:42:32 UTC
The new recursive search is nice but the non-recursive search is needed. Consider this scenario: The user just wants to quickly find a file named 'X' inside a directory full of folders containing files with the same name 'X'. Such a search would result in several 'X' files and the user wouldn't know which one is the file he wanted to find. On the other hand, the mere pinpointing of a file inside a folder that contains numerous folders would be CPU-intensive. So, it would be nice to have the non-recursive search back and the recursive one optional.
I agree, we should have a way in the UI to make recursive search opt-in. Some possible ideas: - add a checkbox close to the search entry (and maybe remember its last state when performing the next search) - always perform non-recursive search by default, and add a button in the view, below the search results, to perform an additional recursive search for the same query
Both ideas are great, especially the first one. Another way is to make filtering and recursive searching separate from each other, like in Dolphin, but I think your first idea is better suited to Gnome's minimalistic look.
I have just experienced recursive search having updated to Ubuntu 13.04, and find the lack of non-recursive very annoying, as it breaks keyboard navigation in a directory. +1 to non-recursive search by default.
@ David Balch I reported this issue for v3.7 hoping that the search mechanism would be practical in the stable version 3.8 but, except for Cosimo's aggreement, they didn't pay attention to it. Now, Gnome users have to tolerate it for six months, at least.
(In reply to comment #0) > The user just wants to quickly find a file named 'X' inside a directory full of > folders containing files with the same name 'X'. Such a search would result in > several 'X' files and the user wouldn't know which one is the file he wanted to > find. This can be addressed by indicating the path of the files: bug 374661, bug 697187
(In reply to comment #5) > This can be addressed by indicating the path of the files: bug 374661, bug > 697187 I'm afraid that won't solve the issue completely because a folder may contain so many other folders, each of which may contain many files. In such a case, the recursive search would cost a lot of CPU usage just for finding a file in the parent folder. The non-recursive search isn't just a luxury. A good file manager should have it, for example, in form of filtering. And Nautilus had it before recent changes.
(In reply to comment #6) Bug 374661 and bug 697187 address the issue I quoted, dealing with files with the same name but different paths, which is orthogonal to CPU usage. My intention was to focus this bug report on the CPU usage issue.
*** Bug 701133 has been marked as a duplicate of this bug. ***
Just created an account to add to the complaints. Search when you need jump is just wrong. Even if it takes a blink of an eye, it's still a blink of an eye and a noticeable delay. You just can't win. I have basically stopped using keyboard with nautilus because every time I accidentally start typing and it searches and blinks and rearranges, I die a little inside. I've already seen a lot of valid cases people present to you that you ignore or mark as uncommon. You shouldn't be so blind to the facts, though or else you risk losing your users. You may think you have foreseen and covered all cases, but there are a lot that a lot of people can do with your tools that you may have never known about. A use-case I have for you that is now impossible is jumping to files/directories that are not what you want, but are located next to what you are searching for. For example, think of the following directories seen in nautilus: aaaaaa bbbbbb cccccc dddddd ddddde dddddf dddddg eeeeee ffffff gggggg hhhhhh iddgdg If I want to get to directory dddddg, I have the following options: 1. type dddddg 2. type d followed by 3 times right arrow 3. type e followed by left arrow 4. type c followed by down arrow 5. type h followed by up arrow With the new search on type, only options 1 and 2 are possible which require more keystrokes than options 3, 4, 5. So please, put search behind CTRL+f and put back the normal jump to file/directory as default. If not, at least give an option for us to set it back to the way it was.
@Shahbaz So many examples of how the Gnome devs apparently fail to see obvious usability issues simply indicates that they CHOOSE to ignore them. Their motive for this odd behavior is still a mystery to me because I don't see any real difficulty in fixing all those issues.
Tsu, no, it is just a matter of not having enough time and manpower to do everything at once and "from the start". Please stay polite and respectful.
I really like to believe that because I loved Gnome and used it since 2004 but there's a lot of evidence that points to another direction. The Gnome devs seem to HAVE plenty of time and manpower to make Gnome hard to use, to remove its useful features, and to add "features" that make it unusable. I've made patches which fix some issues in different parts of Gnome3, and I applied them for my personal use as long as I used Gnome3, but I never proposed them knowing about the Gnome group's reputation of rejecting patches for ridiculous reasons. However, I don't intend to start a discussion of this type in a bug report.
Use case: If I've got two directories, 'DirOne' and 'DirTwo', and each has a file called 'Document.txt', and I type 'Document', I get both files. I have no idea which is 'DirOne/Document.txt', and which one is 'DirTwo/Document.txt' I encounter repeated filenames frequently with cameras, backup disks, and source code version checks. This issue drives me nuts. These filenames are admittedly a mess. One purpose of a filemanager is to be able to clear up this mess.
*** This bug has been marked as a duplicate of bug 681871 ***
*** Bug 723992 has been marked as a duplicate of this bug. ***