GNOME Bugzilla – Bug 697187
location column in search results should show relative paths
Last modified: 2013-07-11 23:22:18 UTC
To see the problem: 1. Perform a search under a folder in Nautilus (i.e. not an All Files search). 2. Use the Visible Columns dialog to add the Location column. 3. Notice that the location of each search result includes the full path of the folder where you began the search. This clutters the display and makes it especially difficult to read if that path is long. I think in these search results each Location should be a path relative to the folder where you searched. In an All Files search we should display full paths.
Hi, Adam, This bug report issue's solution looks like a similar logic to the one I applied in resolving bug 699118 except. Of course, nautilus code is in C and previously I have coded in Vala. From what I have done in the previous bug, I know how to replace '/home/$USER' with '~' but I don't know how I could generate the "../../....." depth required for folders that are nested, since you say the paths must be relative to the folder where searched from. How do I go about this? If I were to attempt solving this bug? Also, I confirm this bug exists and changing bug status to 'NEW'. Thank you.
Sindhu, thanks for your interest in this bug. But actually Garrett Regier (who is doing some GNOME bug fixing work sponsored by Yorba) is already working on this - he wrote that he already has a mostly working patch and just needs to fix one edge case. So probably you should pick another Nautilus bug to work on - there are plenty more. :)
(In reply to comment #2) OK I was not aware of that :) I will, thanks!
Created attachment 248964 [details] [review] Bug 697187 - Show relative paths in location column when searching Should I also implement replacing $HOME with ~/ ? It would really reduce the location column's size.
Review of attachment 248964 [details] [review]: This looks good to me, except for the following style comment. ::: src/nautilus-list-view.c @@ +1817,3 @@ gtk_tree_view_column_set_sort_order (column, sort_order); + + if (!strcmp (name, "where")) { Please make this a direct == 0 comparison, it's more readable that way.
(In reply to comment #4) > Should I also implement replacing $HOME with ~/ ? It would really reduce the > location column's size. In what situations would $HOME be displayed if we're only showing relative paths? If this is for searches from locations above $HOME, I think it's fine to display the full path.
(In reply to comment #6) > > In what situations would $HOME be displayed if we're only showing relative > paths? If this is for searches from locations above $HOME, I think it's fine to > display the full path. I agree.
(In reply to comment #5) > Review of attachment 248964 [details] [review]: > > This looks good to me, except for the following style comment. > > ::: src/nautilus-list-view.c > @@ +1817,3 @@ > gtk_tree_view_column_set_sort_order (column, sort_order); > + > + if (!strcmp (name, "where")) { > > Please make this a direct == 0 comparison, it's more readable that way. Should I also change the one about 20 lines above this one? I was attempting to keep the coding style consistent within the file. (In reply to comment #6) > (In reply to comment #4) > > > Should I also implement replacing $HOME with ~/ ? It would really reduce the > > location column's size. > > In what situations would $HOME be displayed if we're only showing relative > paths? If this is for searches from locations above $HOME, I think it's fine to > display the full path. I meant that I could also replace $HOME with ~/ when not searching. Of course, I would do that in another patch.
(In reply to comment #8) > Should I also change the one about 20 lines above this one? I was attempting to > keep the coding style consistent within the file. Oh, in that case it's fine as-is then. Feel free to push! > I meant that I could also replace $HOME with ~/ when not searching. Of course, > I would do that in another patch. I think that's also a good idea! Feel free to open another bug for that.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.