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 607303 - [RFE] Nautilus search results should indicate full path to files it finds
[RFE] Nautilus search results should indicate full path to files it finds
Status: RESOLVED DUPLICATE of bug 374661
Product: nautilus
Classification: Core
Component: File Search Interface
3.1.x
Other Linux
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 656528 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-01-18 13:52 UTC by Tomas Bzatek
Modified: 2012-07-20 12:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tomas Bzatek 2010-01-18 13:52:10 UTC
(originally opened in https://bugzilla.redhat.com/show_bug.cgi?id=555821)

Description of problem:

This is an enhancement request. In Nautilus' search results display, please
make the status bar show the full path of each file as the user selects it.
Often it is necessary to know WHERE a file is located, and currently the only
way to find that out is to right-click on each in turn and select "Properties"
from the pop-up menu.


Version-Release number of selected component (if applicable):
2.26.4


How reproducible:
Always


Steps to Reproduce:
1. Open a File Browser window and navigate to /
2. Click on the "Search" button
3. Enter "stdlib.h" in the search box and click and press Enter


Actual results:

On a development machine, many copies of stdlib.h may appear in the results
window. But how to know which is which? If you click on one of them to
highlight the file, the status bar changes to say '"stdlib.h" selected',
telling you exactly what you already knew before you even clicked, not what you
need to know.


Expected results:

When a search results window is displayed, clicking on the stdlib.h which is
located in /usr/include should cause the status bar to change to say
'"/usr/includes/stdlib.h" selected' so that you don't have to waste time
checking the properties of each file to find out which one it is.


Additional info:

I apologize if this is not the correct forum for entering an enhancement
request. RetHat's site says this bugzilla is for bug reports and enhancement
requests, but once I log in, I am only offered the option of entering a bug
report.
Comment 1 Stefano Teso 2011-02-09 18:01:13 UTC
Hi,

yes, this is the correct place to post enhancement proposals :-) and I agree that this particular bug is indeed very annoying.

This bug is related to bug 374661, which however does not _suggest_ where to place the location info (it just asks to display it _somewhere_). I don't think it is a duplicate anyway.
Comment 2 André Klapper 2011-08-11 18:43:39 UTC
For the time being, you can right-click > Properties > Location.
Still valid in 3.1.4.
Comment 3 André Klapper 2011-08-18 14:57:10 UTC
*** Bug 656528 has been marked as a duplicate of this bug. ***
Comment 4 uuups_123 2011-08-18 17:54:28 UTC
(In reply to comment #2)
> For the time being, you can right-click > Properties > Location.
> Still valid in 3.1.4.

The proposed workaround right-click > Properties > Location is
suboptimal, because:
- not userfriendly (right-click on every file in the result; no overview),
- no sorting by path,
- no possibility to "open folder which contains the file" for a file (like for folders in the result).

This feature is missing for so many years. It would be nice to know, if the possibilty exists, that this feature will be implemented.
Comment 5 uuups_123 2012-02-10 22:21:08 UTC
I found a solution! :-)

Edit > Preferences > Columns > enable Path
[sorry, I don't know the exact english translation, because I use a different language]

Then you can see the path to every file also in the result of a search.

Note: This only works in the List-View, of course.
Comment 6 William Jon McCann 2012-07-20 12:40:33 UTC

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