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 703629 - Provide context - allow users to know the path / location from where files and folders in search results come from
Provide context - allow users to know the path / location from where files an...
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File Search Interface
3.8.x
Other Linux
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 708587 712359 (view as bug list)
Depends on: 697187
Blocks:
 
 
Reported: 2013-07-04 19:13 UTC by Jean-François Fortin Tam
Modified: 2016-02-10 03:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot (227.78 KB, image/png)
2013-07-04 19:13 UTC, Jean-François Fortin Tam
Details

Description Jean-François Fortin Tam 2013-07-04 19:13:01 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 :)
Comment 1 António Fernandes 2013-07-04 21:31:56 UTC
(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
Comment 2 António Fernandes 2013-07-04 21:54:49 UTC
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.
Comment 3 André Klapper 2013-09-23 11:24:47 UTC
*** Bug 708587 has been marked as a duplicate of this bug. ***
Comment 4 Jean-François Fortin Tam 2014-01-13 01:22:41 UTC
*** Bug 712359 has been marked as a duplicate of this bug. ***
Comment 5 Michael Catanzaro 2014-01-13 15:29:20 UTC
(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.
Comment 6 Jean-François Fortin Tam 2016-02-10 03:22:16 UTC
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.