GNOME Bugzilla – Bug 703629
Provide context - allow users to know the path / location from where files and folders in search results come from
Last modified: 2016-02-10 03:22:16 UTC
Created attachment 248408 [details] screenshot The big (and pretty much only) problem I have with the current filtering search interface is that it tends to search everywhere (and not necessarily just subfolders as it uses Tracker?)... leading to terrible situations like what you can see in the attached screenshot. I'm not sure if simply enabling the "Location" column in search results by default (in which case you also need to fix bug #697187) is the solution, or if it would make more sense to use a treeview/hierarchical approach, where you would actually *show* the various folders leading up to a match (ignoring non-matching files). Maybe with those "intermediate" folders greyed out / showing with 50% transparency to indicate that they're intermediate steps and to reduce visual complexity. Either way, I trust you guys to make it better :)
(In reply to comment #0) > (and not necessarily just subfolders as it uses Tracker?) Unless you click on the "All Files" button in the search bar, it will necessarily search under the current folder and its subfolders. > I'm not sure if simply enabling the "Location" column in search results by > default (in which case you also need to fix bug #697187) is the solution, It is already enabled by default in git master[0]. I agree that bug 697187 should be fixed before the final release. And even so, it may eat too much horizontal space and it would make bug 698017 even more serious. > or if it would make more sense to use a treeview/hierarchical approach, where > you would actually *show* the various folders leading up to a match (ignoring > non-matching files). Maybe with those "intermediate" folders greyed out / > showing with 50% transparency to indicate that they're intermediate steps and > to reduce visual complexity. It would conflict with the sorting results by relevance (files under the same tree do not necessarily have the same Relevance ranking). [0] https://git.gnome.org/browse/nautilus/commit/?id=e3ca31da5539de8f3fb067a4de21238a79b97b13 See also: bug 311875
I'll add an idea too: A specialized list view, where a relative path is shown in a second line, except for results from the current folder, which are above a separator. Example search for "foo": ___________________________________________ FOO 5 items Folder foolder 2 items Folder foobar.odt 5 KB Document _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ fool.png 5 MB Image ./foolder fool.png 5 MB Image ./foolder/old football.webm 15 MB Video ./sports infoo.txt 15 MB Document ./really/really/really/really/long/path ___________________________________________ With this, we could see path and name at a glance. And long paths would not mess up with columns. Path would have lower contrast than name.
*** Bug 708587 has been marked as a duplicate of this bug. ***
*** Bug 712359 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > I'm not sure if simply enabling the "Location" column in search results by > default (in which case you also need to fix bug #697187) is the solution, I think this would be a very good start. Search is currently very painful, and list view would go a long way to alleviate that.
Oh hey, actually, this has been fixed (with 3.10 I think), the location column is shown by default nowadays and it's showing relative strings! Let's put this to rest then.