Michaël, the message I was replying to is not about copying the current path. It’s about opening a path that’s currently in the clipboard (e.g. a path that’s been copied from a web page). This is the missing piece of the puzzle.
I guess I should start the brainstorming myself. I have two ideas:
Have an “Open Copied Path” menu item, which is available only if the clipboard contains a path.
I don’t like that it’s a little unpredictable as it doesn’t tell you what’s copied. Technically, monitoring the text clipboard is possible but I’d like to avoid doing that.
Make search smarter: if you paste a path into the search bar, you get that folder as a search result.
I like this idea a lot more, and haven’t been able to find any drawback. Feedback welcome.
“Open from clipboard” is a common operation in various applications, and it’s actually a feature on mobile as, of course, keyboard copy/paste isn’t a thing there.
That’s what I thought too (my message was about something like that, I meant “we have the Copy Location, so why not an entry like this?”; but, yes this was confused).
If we assume that users are directly pasting a path they just copied, why not? But if you have reasons for not monitoring the clipboard (I assume detecting a path?). Also, if find “Open Copied Path” odd because most actions apply to the location.
Why not. But I think we want to change the location, rather than using search to navigate to a location. The question is: What prevents just adding an “Edit Location” entry, when there is the keyboard shortcut mentioned in “Keyboard Shortcuts”?
In the current location menu, I agree it feels wrong. It would be more logical in the primary menu, but I doubt that’s where people would go look for it.
I believe actually “editing” the current path is an edge case. Most commonly, people just erase the existing content, typing a new location from scratch. And you can already just type.
The common case where the current path is actually relevant is when you want to copy it. And that’s already a solved problem with the existing menu item.
In the edge case when one actually wishes to edit the current path, it can be copied, edited, and entered. It’s slower, but we should optimize for the common cases, not the uncommon cases. Optimize for the “Paste new path from clipboard” is more worth it in my opinion.
I agree that this is probably a rare case. However, in a tactile case (mobile, tablet, touch screen), it would be necessary to have it, as it has already been said in other issues: we tap on Edit, then the keyboard is displayed to edit the path, and there is the action to paste.
With “Open from clipboard”, “Open Copied Path”, or “Paste new path from clipboard”, it will certainly work. It’s just that the label doesn’t make sense if the item is placed in the location menu for the reason I stated. The wording should be changed (if possible).
Pasting into the search box is still an option, but I think this needs to be tested with users who are blind to the addition of this feature (but they need to think it’s possible to paste a path). It doesn’t seem intuitive to me, maybe because it’s not the usual way in other operating systems. But this has the advantage of not monitoring the clipboard.
Another alternative is to display a banner, but this requires clipboard monitoring. This banner should ideally be displayed below the path bar (so above the sidebar and file view). It can say something like “A location has been copied. Go to it?” and have a “Go” action. Obviously, this banner does not display when the current location has been copied.
I believe actually “editing” the current path is an edge case
Very true. I’d imagine the reason people want to access the address is almost entirely to copy/paste it (except in some rare cases).
I’ll continue to point out that pretty much every other file manager (including Windows) has the behavior of highlighting the whole path when you click on the last breadcrumb / after it. That’s why I was hoping it could at least be a setting in the preferences menu, even though understandably it’s not the default option.
As far as the alternative methods you’re suggesting. Needing 2+ clicks to copy or paste the path does take a bit more effort. Especially if you copy/paste paths all the time (which my and many of my co-workers do). I do wonder if the people who want this functionality would be satisfied with an option in the preferences to allow clicking the last breadcrumb. My opinion is that this, while still retaining the method you’re discussing, would cover all the bases.
I think adding more options to the menus like a additional menu entry to paste a path is just a very complicated solution that tries to reinvent the wheel if its not necessary at all. Why overcomplicate things if there are simpler solutions available that people are used to that a familiar with other OSs/DEs and their file manager apps.
The folder menu option to copy the path is nice to have for touch input but if i had an quick an easy way to access the location input, i probably just use CTRL-C as the path is preselected anyway , no need to navigate any menus…
Clicking on the current folder has not function bind to it and who would be confused if he accidentally clicked on it and get presented with the raw path?
Especially since when you click anywhere outside of the input field the widget switches back to the breadcrumbs.
I also have similiar workflows like @Regrews3 apparently and quite often paste paths input nautilus that navigate me easily to a specific location or i need to copy a location for others. I have notes full of paths for some projects and this allows me to relatively quickly access those locations.
Starring or Bookmarking those would be a complete mess
I know this is probably a niche usecase but i don’t get why a feature like this that would not interfere with other functions or workflow, is very low maintenance and is requested over and over again is such a big issue.
If you access these locations frequently (even if once a week), we may wonder why you are not using Starring or Bookmarking.
Having the path bar editable with one click like in web browsers would conflict with navigation. The double-click to edit does not seem discoverable to me because not common if we take the address bar as a reference.
Maybe as another small improvement, CTRL+L can be made permanent until retriggered or cross clicked?
How would this (single click) conflict with navigation? The current folder has no function bind to it anymore since this was moved exclusively to the three-dot-menu.
And yes i agree double click wouldn’t be that discovereably but so is CTRL+L I proposed this originally because you would not access it accidentally but in hindsight i would say single click would be fine as well. Yes there is a change that you “discover” this accidentally but would this be an issue? I think it even makes sense as CTRL-L displays the current path anyway.
My ideal implementation would be having a simple GUI way to access it (single click) and this would behave like the current CTRL-L, so it would revert automatically to breadcrumbs if you confirm an entered path (press enter) or click anywhere outside the input widget.
CTRL-L could then be used to make this a bit more permanent (atleast for this “session”) so you would have to press CTRL-L again to revert to breadcrumbs if you don’t close nautilus completely.
The logic is to use already known behaviors. The reference behaviors are those of the address bar of a web browser for a single click, and of the text selection for a double-click.
To have single click, the pathbar must be clickable anywhere. However, clicking on a folder will go to this one: that’s the conflict with navigation.
For double click, the path must be presented as selectable text (what we have when Ctrl + L is pressed). But it will prevent navigation with one click.
Just read through this thread again on my desktop, i missed a few replies that were posted on other replies before.
I actually really like @antoniof 's idea of using the search function for pasting a path.
That would be an easy method without having to access any submenus, either use the button or press CTRL+F + CTRL+V.
This could be limited to strings beginning with “/” or “~/” and would correspond with the behaviour of type to search in nautilus/files.
If you press CTRL+C on a selected file/folder it copies the path in the clipboard, i would propose that the same behaviour would copy the currents location path if you don’t have any items selected.
I also noticed that the copy path option is available in the folder menu (3 dots) but is missing from the right click menu. Is this intentional or was this just “missed”? I am using an up to date Fedora 37 with Files 43.1
For completeness sake a function to show the path input widget (like CTRL+L) should be added to the folder menu (Show full path CTRL+L) so this functions is available for devices without a keyboard and not only mentioned on the hotkeys screen.
This is was an intentional design change. Previously the two menus were supposed to be the same (because the background context menu was inaccessible in full lists). Now that the context menus are always accessible, designers asked for some actions to be present only in one of them.
I proposed this originally because you would not access it accidentally but in hindsight i would say single click would be fine as well. Yes there is a change that you “discover” this accidentally but would this be an issue? I think it even makes sense as CTRL-L displays the current path anyway.