Another release of GNOME and Nautilus is coming, 3.24. As we have been doing for every release I will explain the changes that have an impact on the users and explain the reasoning behind them, and also a brief look into what we worked on this release.

User changes

Accessing root files – The admin backend

Since Nautilus was created, if a user wanted to open a folder where the user didn’t have permissions, for example a system folder where only root has access, it was required to start Nautilus with sudo.

However running UI apps under root is strongly discouraged, and to be honest, quite inconvenient. Running any UI app with sudo is actually not even supported in Wayland by design due to the security issues that that conveys.

So now we put a gvfs backend (kudos to Cosimo Cecchi) and we added support in Nautilus to open folders and files with no permission to access then conveniently into Nautilus itself. Now if you try to open a folder that requires special permissions it will ask for the root password with a dialog and once provided it will allow the user to navigate them without needing to restart the application or opening a new instance. The password is saved with a timeout so you can use access the file for some time, as is common with PolKit.

Also this allows to use Nautilus to access these files when using Wayland.

Here’s a demo how it works:

Operations button

Two releases ago we introduced a new way to handle operations in Nautilus, using an integrated popover rather than a separated window. We also added a button that shows a pie chart with the completion progress of the operations.

One issue we faced is that this button was not visible enough when an operation started, making the user think nothing was happening and the operation didn’t actually started.

For that we added an animation that makes the button shine, but seems that was not enough and after going back and forward through some solutions we end up showing the operations popover when and operations started, which is the last resort we could go with.

This is by far the least ideal solution, since it kinda disturbs the user and makes them dismiss the popover in every window (because where do you show it? only in the source of the operation? only in the destination? only where the user is looking at? everywhere?)

So we created a new animation that tries to catch more attention, and we will like to receive some feedback on it. Here is a demo:

And so far we didn’t add any user change more, so it should be a good release for those that like stability.

Nautilus desktop works on Wayland sessions

Thanks to Florian Mullner, he came up with a simple but working solution. Now you can use the desktop when in a Wayland session. Keep in mind this requires XWayland, and it’s backported to 3.22 too.

What we have work on

Flow box view

As you may know, the views in Nautilus are quite old and on the technical side they lack the most basic modern stuff, due to it’s custom implementation. For more than 2 years we have been working on allow a new view based on GtkFlowBox to be created.

Issues with current implementation are:

It’s not using gtk+ widgets or containers. This is by far the most important issue: Any change or new feature requires a whole “widget alike” object creation. We cannot use any of the gtk+ widgets technology, including the gtk+ inspector or CSS We cannot really create new visualisations like a placeholder for when copying files with some progress information or showing tags for files or any smart feature you could think We have to maintain a big amount of code that Nautilus shouldn’t. This is widget work from gtk+

Spacing between items is not dynamic

Selection of items modify the visual of the picture, videos, icons with a blue overlay

We cannot have several zooms without making the view unusable.

The view and items “jumps” while it’s loading the files inside, making effectively useless to use Nautilus while the directory is being loaded.

This work it’s without hesitation the hardest and longest that Nautilus have faced for years. It required the desktop to be split from Nautilus, it requires modification in the most basic level of the code, porting to new technologies, etc.

Unfortunately, even if we managed to make all of this work, due to its performance issues we cannot switch to GtkFlowBox yet, and more work is required both in Nautilus and gtk+.

However I’m happy to announce that on the Hackfest we did last Novermber we decided to push forward this as a optional view to be able to iterate on its implementation and open the door for contributions from contributors and GSoC projects on it. This work is an experiment in several ways, not only in the technical part but also in the views itself and the code design. We will iterate on the feedback and code to make it shine before making it the default view. The same will apply to the list view once the icon view is ready.

This experimental view is now optionally checked as a gsetting called “use-experimental-views”. It’s not yet in the user preferences because it’s not in a usable state and it’s not intended to be used by nobody other than developers contributing to Nautilus.

Probably most of you already saw how this looks like on some of my posts in social medias almost a year ago. The state now is much better, here it is:

What did not make it into this release

You can take a look at the roadmap of Nautilus to see that most of the items I planned for this release were not implemented. Instead we implemented two different ones, the admin support and the new icon view.

This is expected, we decided a year ago to do a “tick-tack” release pace. Than means, one release with a lot of new changes and one with stabilisation and improvements in mind, and we kept that promise. We needed to stabilise and improve the new features, like the batch renaming and the decompression support, that we added last release.

So actually there are the same items that couldn’t be included and were mentioned in the previous release blog post.

The reasons this time are different. For the path bar, it was mostly because of the work in gtk4. We don’t want to have different path bars in gtk file chooser and Nautilus. So I would say we need to port Nautilus to gtk4 before committing the new path bar to gtk+. And that requires more work, and to gtk4 to stabilise a little.

For the action bar, was mostly because we need more design time on it. The difficulty in this project is not technical, but design wise.

You can look more details and bug fixes in the NEWS file.

Hope you enjoy the new release! As always, feel free to give any feedback or ask any questions in the comment section of this blog, be constructive please 🙂