'Open Folder' in Search for Files is a misleading option for folders and opens the parent directory

Bug #396966 reported by Victor Gijsbers
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Fix Released
Low
Andrew Fister
gnome-utils
Fix Released
Medium
gnome-utils (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

After using the standard graphical search tool in Ubuntu (Places > Search for files...) to search for files, you are shown a list of files and folders that match you description. Right-clicking on a file gives the option "Open" and "Open folder", which is very clear. The first will open the file, the second the containing folder.

Right-clicking on a folder will give the same two options, "Open" and "Open folder". But in this case these options are confusing, because "Open folder" sounds like it will open the folder you are looking at, but does not--it opens the containing folder. It has happened to me often that I click "Open folder" without thinking, and get to where I do not want to be.

All of the three following schemes seem clearer to me:

1. For folders, change "Open folder" to "Open containing folder".
2. For folders, change "Open" to "Open folder" and "Open folder" to "Open containing folder".
3. For folders, remove the option to open the containing folder altogether. (Unlike opening a file, opening a folder will take you the file manager anyway, where the containing folder is only a single mouseclick away.)

Related branches

summary: - Open folder option in Search dialogue is misleading for folders
+ 'Open Folder' in Search for Files is a misleading option for folders and
+ opens the parent directory
Changed in gnome-utils (Ubuntu):
importance: Undecided → Low
Revision history for this message
Sense Egbert Hofstede (sense) wrote :

I'm accepting this as a papercut as this is indeed a usability issue that shouldn't be too hard to fix. Thank you for taking the time to report this issue and providing us with three possible solutions.

Not to people willing to fix this issue: please make sure to fix this early in the cycle as not to upset the translators and the release manager by violating the freezes.

Changed in hundredpapercuts:
importance: Undecided → Low
status: New → Triaged
Changed in gnome-utils (Ubuntu):
status: New → Triaged
Changed in gnome-utils:
status: Unknown → New
Revision history for this message
Andrew Fister (andrewfister) wrote :

I believe I have solved this issue. I have attached a branch with the fix. Please have a look and let me know :-)

Changed in hundredpapercuts:
status: Triaged → In Progress
assignee: nobody → Andrew Fister (andrewfister)
Revision history for this message
Vish (vish) wrote :

Andrew Fister, Thanks for working on this bug. Could you submit your patch upstream as well on https://bugzilla.gnome.org/show_bug.cgi?id=619499 ?

Revision history for this message
Andrew Fister (andrewfister) wrote :

Alright, I have attached the patch(the diff linked from my attached branch above) at the GNOME bug report.

Changed in gnome-utils:
importance: Unknown → Medium
Changed in gnome-utils:
status: New → Confirmed
Revision history for this message
Vish (vish) wrote :

This has now been fixed upstream.

Changed in hundredpapercuts:
status: In Progress → Fix Committed
Changed in gnome-utils (Ubuntu):
status: Triaged → Fix Committed
Changed in gnome-utils:
status: Confirmed → Fix Released
Revision history for this message
john morimore (paradigmshifter1) wrote :

did not work first day with ubuntu any adbvice ? :)

Changed in gnome-utils (Ubuntu):
status: Fix Committed → Fix Released
Changed in hundredpapercuts:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.