Development of the nautilus project has picked up the pace for version 40, thanks to contributions from multiple people, new and old contributors alike.
I’ve previously blogged about the new Creation date property and the enhanced Wallpaper action, and this time I’m talking about changes which have made it into the beta or are set for the final release. There is a mix of enhancements, bug fixes and redesigns. And lot of screenshots.
Tab-completing path typing
The Files app has got a keyboard-only interface which allows navigating into a folder by typing a path. You can just start typing a path beginning with /or ~ to enter this mode, or Ctrl L if you want a relative path from the current location.
James Westman has enhanced this feature with automatic path completion suggestions. Read James’s blog to see it in action. It’s much more useful and enjoyable now.
File conflict automatic renaming
I’ve implemented an usability improvement which has been suggested by Jon McCann: if you move or copy a file but don’t want to overwrite another file with the same name, a new available name is automatically generated:
Transfers & operations progress estimations
Making estimations on file operations is hard! Many factors may affect the speed, and unexpected file conflicts may change the final number of handled files compared to the initial count.
Over the years we have received reports of some weird results: unrealistic time estimations, incomplete progress bars for finished operations, number of files moved exceeding the total, etc.
Thanks to valiant efforts from Sachin Daluja and Ondrej Holy, the most visible and jarring bugs have been fixed, and the structure of the code has been improved.
Extracting password-protected files
After bringing us the new Wallpaper portal integration, Felipe Borges has extended our simple extraction process to handle password-encrypted archives correctly. Instead of failing without any explanation, Files now asks the password as it should:
Running scripts directly
The Files app has always featured the option to run executable text files (commonly “scripts”). However, it’s been hidden in a Preferences section requiring people to make an awkward compromise between opening (e.g. in a text editor) or running.
A couple of years ago I’ve ignited a community brainstorm about running executable files from the Files app. Revisiting the very useful feedback and discussion from that time, I’ve implemented a simpler, safer and more empowering solution: a new action to the context menu.
This new action comes with a bonus: it runs scripts in a Terminal window, which ensures the user gets feedback from and control over the script’s execution.
With both Open and Run available in the context menu for executable text files, the old preferences option became obsolete, which, along with a few other optimizations, has prepared the ground for the…
… redesigned Preferences!
Starting from Sam Hewitt’s design, this was further polished by Tobias Bernard and implemented by Adrien Plazas.
In addition to looking modern, the new Preferences dialog organizes the options in a more straightforward fashion, and describes them in clearer and more helpful ways.
Smooth visuals
You may have noticed the Preferences window has rounded corners all around. This feature has been extended to the main window, and Preferences too, by Christopher Davis.
Testing
For testing the latest developments in GNOME Files, without modifying the Files app in your system, there is a Nightly flatpak. To install it, copy and run the following command in a Terminal:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
The Nightly can now be launched from Activities, or with this command:
flatpak run org.gnome.NautilusDevel
(If your operating system doesn’t support flatpak out of the box, see the Quick Setup guide.)
Thanks for this excellent work and progress!
Some thoughts about the UI for ‘replace or rename’ on a file move/copy conflict …
On the conflict UI window, the ‘Rename’ button is now obvious, but what do the buttons ‘cancel’ and ‘skip’ really do?
I’m not sure it would be clear to a casual user.
I guess there are 3 options a user might want:
1) Rename (you now have a clear button for that)
2) Go ahead and over-write the pre-existing file
3) Don’t do the move/copy on this file
Its not clear which of skip and cancel do 2 or 3 above.
I suppose a user might even like a 4th option: abort the whole move/copy. A difficulty with that is if it is a mass move/copy … and some of it is already completed but the user doesn’t know how much.
Keep up the good work!
Thanks for the feedback. I’m glad to know more people feel the same. I’ve explored a limited redesign here https://gitlab.gnome.org/GNOME/nautilus/-/issues/1344#note_686825, but there is a better, but more radical proposal linked too.
The mockup you link looks to me to be going in the right direction … making it very clear what will happen out of the radio-button choices presented.
I tried to install the Nightly flatpak on Ubuntu 20.04, but I got the following error:
error: The application org.gnome.NautilusDevel/x86_64/master requires the runtime org.gnome.Platform/x86_64/master which was not found
How do I install that runtime? And shouldn’t it be installed automatically if it’s missing?
Thanks for letting me know! There was an error in the manifests; I’ve fixed it now, so the next Nightly update should just work. If you don’t want to wait for that, you can add the repo first, then try to install the app again.
flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepoAs keyboard user I appreciate the improvements to the keyboard-interface and tab-completion. Thanks for your work!
Keyboard users always favor convenience and speed 🙂
The work that has been done with Nautilus through the years is great, I really like the design. It happened that I’ve installed Nautilus even under Kde 🙂
Just one thing (only 1) is still annoying…
It would be great if you could create a new file “via right click” the same way you create a new folder: right click → new folder → a little window appear with a text field where you write the name of the folder. Finished.
Creating a file using the right click option is harder:
– On right clicking, you don’t have any option at all to create a new file, unless you create a file inside the Models folder.
– If you have a file in the Models folder, then you have the right click option, but everything you can do is selecting one of the file inside Models folder and a copy of it will be created in the current directory.
– It’s not finished because of course you want to give a proper name to your file, so you have to select your new file and then press F2 or choosing the right click option to rename it.
Please make things so that with or without existing files inside Models folder, you can immediately create a file and immediately write the name.
Ciao
Indeed, Jeremie, the new documents feature is not performing well, and I think it needs a complete redesign and/or reimplementation.
https://discourse.gnome.org/t/bringing-back-the-new-document-button-on-right-click-by-default/
However, making it easier to give the new file a name is a possible enhancement in short term: https://gitlab.gnome.org/GNOME/nautilus/-/issues/524
I don’t think that “Run as a Program” option is a good idea. First of all it is very easy to misclick compared to the current behavior, which makes it all far less secure. Secondly judging only from the screenshots it is unclear to me if there is an option to prevent running executable scripts at all, which at the very least would mitigate the aforementioned problem.
Also a dconf option (not in nautilus preferences panel) to toggle the run in a terminal behavior would be very welcome.
Yes, there is still a small risk of activating the menu item by mistake.
Before this change the risk was larger, because running scripts would use the main action (double-clicking or single-clicking, depending on the user preferences).
Running is the main action for executable binary files, and there is no preference for it. The “Run as a Program” action might be a step in the right direction for executable binary files too.