GNOME Bugzilla – Bug 701413
Search shouldn't affect the path bar
Last modified: 2018-06-20 15:29:39 UTC
If I enter a search, the path bar changes to a "Search for "foo"" location. To navigate away from this search location I have to press back. This doesn't fit with the current approach to search, which is bound to the current location. If I am in ~/Pictures and I search, I am searching within the ~/Pictures directory, for example. To be consistent with this model, the path bar should continue to indicate the current directory when a search is active.
I think this should be done so that the path bar does not pretend that the search view is the same as the folder where the search was initiated, because some of the search results may come from sub-folders, and folder-specific actions are not available/don't make sense when in search view (such as Paste, see bug 693394). I see two ways how this could be avoided: 1) Don't show the path bar button in the pressed state. Example: [Home][Pictures], where the Pictures button is not pressed. It can be pressed to go back to the folder. OR 2) Represent search in the path bar as a child of the folder where the search was initiated. Example: [Home][Pictures][Search for "foo"].
(In reply to comment #1) > I think this should be done so that the path bar does not pretend that the > search view is the same as the folder where the search was initiated, because > some of the search results may come from sub-folders, The path is relevant in the recursive search case too, though. It indicates the location from which you are searching. > and folder-specific > actions are not available/don't make sense when in search view (such as Paste, > see bug 693394). ... Paste should be possible, I think (see my comment on bug 693394). Are there any other actions that are problematic?
(In reply to comment #2) > The path is relevant in the recursive search case too, though. It indicates the > location from which you are searching. Absolutely. What I meant was to append «Search for "foo"» to the path, but thinking again, maybe there is no need for that. > Paste should be possible, I think (see my comment on bug 693394). Are there any > other actions that are problematic? "Properties" and "Bookmark this Location". The Properties window of a search is pointless, while Bookmarking a search query is broken (I will write a bug report about it).
3.14 is over - move to the 3.16 target milestone.
-> 3.18 with the work we are planning for the path bar and with the work on nautilus view abstraction to not always rely on having a GFile location set. I imagine having an API for the path bar to just set a fake location and nautilus aware that what we are showing is not a location (although in this case it will use a location still, the nautilus-search-directory, but it will fit with the new way we are trying to do for the network&drives view)
ground work is more or less done, but gtkpatbar rework didn't go in master in time. Move to 3.20
Moving to 3.22 with pathbar.
Could you please give any pointers to the ground work which has already been done two years ago? Could you please summarize what else is left to do?
Closing as discussed on IRC: antoniof[m] > Now that the searchbar and pathbar are the same, how can we indicate the current path? aday > antoniof[m]: i'm not entirely sure how important that is in the context of the new design... it seems fairly obvious that you are searching the current location? antoniof[m] > aday, I fear that the new position of the searchbar (headerbar instead of centered in the view) might suggest the search is global. aday > antoniof[m]: it's a possibility... antoniof[m] > Aday, but in my case, I know how it works so it is not an issue unless I switch windows and when I get back I don't remember what the searched location was... But that's not really a problem for me. And back & forward are enough to know where I was searching aday > there might be enough in the interaction to communicate what's going on - the fact that activating search doesn't clear the view, and the fact that we filter items from the current directory first it's a bit hard to tell how users will interpret it antoniof[m] > Good points. I don't worry much about it, I just wanted to have your insight. Thanks. And it allows me close that bug report as obsolete.A aday > it would be cool if someone wanted to do some user testing on this