I would propose to add a double click feature to the current folder name to switch to the path input widget.
This shouldnt break any existing workflows and is similiar to other filemangers so it would make this easier for new gnome users and should also work with touch input in mind.
I have no experience with C or gtk4/gnome development in general but it doesnt look like something that would be very hard to implement or maintain.
I looked at the code and enabling this with a single click action would probably be only one line. To filter this only for double clicks would definatly be more work but like i said i am not familair with C or GTK4.
Why is this needed tho you may ask? I would answer the following:
When you want to enter a path manually in nautilus you have to press (CTRL + L). I am a right handed person (like the majority) and have my right hand on the mouse when using a desktop ui. When i want to copy a path to nautilus im usually using the mouse and have some browser or document open where i copy the path from.
With this “Setup” the combination to access the path isn’t very user friendly imo. I dont have small hands but i cant press (Left-CTRL + L) on normal keyboards with a single hand (without using the thumb).
The current possible solutions are:
Use right hand to press “L” → have to “leave” the mouse
Use both hands → have to “leave” the mouse
Use left hand but use “Right-Control”, not a very natural movment (atleast for me)
I know i can enable the path view by default but then i would loose the breadcrumbs menu which is great and should stay the default.
I agree with you on adding the feature to be welcoming to users migrating from another DEs or OSes. Plus, with this feature, it will be easier to go to a location that a user copied from an article or something.
But did you know, Nautilus 43’s new context menu button has ‘Copy Location’ menu entry?
Yeah i noticed this too, probably wouldnt use it anymore tho if the double click method would be added
CTRL + L is established in other desktop apps to access the path bar (for example browser) but i think this is only useful if you are only using the keyboard and no mouse. As all those other apps also support to directly edit/select path with the mouse.
Imo it is not very user friendly to have en essential function like this only be hidden behind a keyboard shortcut.
Single-clicking on the pathbar’s background should convert the path to an editable string.
In Nautilus 42, a click anywhere past the directory names on the pathbar opened up the 3-dots menu at its tail end, nowhere near where the user was clicking. Fortunately, that was done away with. But now, clicking the pathbar (in the empty space past the directory breadcrumbs) does nothing at all which doesn’t exactly seem sensible either.
And if a single-clicking “textizes” the path, a double-click can be assigned the standard function of text-selecting the entire contents for copy/paste/overtyping purposes.
(Also, separately, that three-dots menu at the end of the pathbar should really have a menu option that’s the equivalent of Ctrl+L. I agree with this 1000%):
Well i proposed the double click because the pathbar doesn’t really have a background. If you have a small window with a long path there is no background to click.
Double click would prevent accidentally going there if you just wanted to move the window and should also work with touch input in mind.
And yes i think entering the path input should always autoselect the whole path. As you would either want to copy it anyway or change the path to something completely different or otherwise you could have used the breadcrumbs widget.
Not entirely true, since no matter how long the path is the current directory name is effctively “background”. Clicking on it also does nothing, so it can be repurposed the same way as the actual background.
Ehhhh… I’m not so sure. It annoys me when browsers do that, for the same reason: Sometimes I just want to edit the end of the path. (Most common reason: I want to go several levels deeper into the hierarchy, but by typing the path components instead of laboriously clicking them one at a time as I descend.)
If any type of click auto-selects, then I have to remember to type End (or →) first, and if I forget and type anything else I immediately wipe out the entire string. That’s been a frustration for me more times than I care to count/admit.
…That being said,Ctrl+L does currently auto-select when activating the path entry, so I can accept a consistency-based argument for doing that when clicking as well.
Well like is said before, common usecase is one hand on mouse and one on the keyboard. I think this is a typical desktop usecase.
And yes copying filepaths FROM files has good working solutions, either select a file and press CTRL+C and CTRL+V (if you want to paste it in a text environment) or use the menu to copy the location path.
The other way around should also be as easy imo.
I know files is supposed to be somehow minimal and focused on the essentials but imo having easy access to the raw path input without using keyboard shortcuts is something that fits in this category as well. The solution i propose doesn’t clutter the existing menus with additional entries and is easily available if you need it.
You can just type a path directly, r same way you can just type to search. No keyboard shortcuts needed. When you start writing a path beginning with / or ~, the path entry shows up automatically.
You can just type a path directly, r same way you can just type to search. No keyboard shortcuts needed. When you start writing a path beginning with / or ~, the path entry shows up automatically.
While this is technically true, it’s (imo) not very intuitive for people coming from Windows or KDE/most other file managers. Is there any reason why clicking on the current folder / space to the right can’t bring up the path editor? I think this would greatly improve the user experince for newbies and not change any existing behavior.
There is no way to paste a path into nautilus/files without using the keyboard.
I actually didn’t now that you could start typing with / or ~ to enter the location input, thats definitely a lot better thant CTRL + L to access this menu.
People coming from Windows expect paths to start with C:\, if they are familiar paths at all. Unix paths are completely alien to them and even the slash which separates directories is reverted. That’s the opposite of intuitive. for people coming from Windows.
In my mind there is a very narrow overlap between “Newbies” and “people who use unix paths”. So, I don’t think it’s crazy to say that having an advanced feature unexpectedly triggered when clicking an empty part of the titlebar would be opposite of improving user experience for “newbies”.
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.
