Nautilus 3.24 – The changes

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 🙂


40 thoughts on “Nautilus 3.24 – The changes

    1. I believe the whole point of this change was that it _did_ do this before, but it was intrusive because it popped up in all open windows, even those that were not relevant to the operation.

      So the new animation is intended to remove that problem, while adding another way to be alerted that something is happening at that button in the toolbar.

    2. (of course, the popup just like you described is still there, but now it is not shown everywhere by default, and you click the button to see the in depth info)

  1. I’m really impressed with the work on Nautilus. It’s good to see some innovation here, as file browsing is definitely a very common operation but there’s ton to do to make it easier! Keep up the good work!

    I’m also working on a GTK+ app, and I’ve wanted to display progress like you do in nautilus with a pie chart in the top bar. Is that a standard GTK+ widget? If not, are there plans to add it?

    1. Using GTK+ Inspector reveals the progress button to be a GtkMenuButton containing a GtkDrawingArea that renders the pie. A grep reveals that the drawing is triggered in src/nautilus-toolbar.c. You could look at the source to see what it does and adapt it.

      1. Thanks, Daniel! Figured out enough to get it to render. Really think this should be a subclass of the regular progress bar or maybe just a different display type as I’m sure it’d be useful for a lot of programs, but at least now I can use it too.

  2. The new animation/popover for file-operations looks nice and the root-file-access is a good thing. One question regarding this:
    Is my assumption correct, that deliberately removing the “admin:///” from location will immediatley drop the gained permissions? So that nobody can’t create root-owned files by accident in the home-dir or even worse, delete important files from the filesystem.

    1. Not entirely, polkit saves the password for some time. UI integration of “locking” this is what’s left in case we need it, although any app using polkit has this “issue”. Right now Nautilus exits the admin prefix as soon as you switch to a folder that doesn’t require it though, but that doesn’t make polkit forget the password or so if the timeout in polkit is not passed.

  3. Thanks! “Right now Nautilus exits the admin prefix as soon as you switch to a folder that doesn’t require it though” is enough for me to fell comfortable 🙂

  4. “This is by far the least ideal solution, since it kinda disturbs the user and makes them dismiss the popover in every window*

    Your user testing showed this?

    Nice work, btw:)
    Bringing back splitview, or, rather, columnar view would get us some ways towards the functionality of the Apple (Smart Folders, btw, would be amazing) and windows file browsers.

    1. Hey, no, we didn’t make any user testing for this. It’s basically the feedback I got from Bugzilla and other downstream communities (Fedora, etc). I would love to make this changes based on user testing, but that requires work nobody except a few people do from time to time (which we all very happy with!) 🙂

      “Bringing back splitview”
      We mostly care about use cases and problems, rather than direct solutions. Then we choose for a solution. In this case, we found out that most of the times the solution is good enough as splitting two windows side by side, and removes this complexity and all the annoying small details that doesn’t work well with split view.
      “columnar view”
      This is miller columns right? I kinda like this. I tested with other apps implementing it. However it’s true that horizontal scrolling it’s not very good, and it doesn’t work in smaller screens. I think the pathbar should kinda work well in this case too. So maybe what we can do is improve the current views/oathbar/whatever so we can avoid putting another view more?

      “Smart Folders”
      What is this?

      1. I like nautilus, but i don’t why no use one tab in preferences for possibility more personalization.

        For example for “columnar view”, you don’t like horizontal scrollbar, but just need one more click to change this, or add in preferences to switch list view and columnar view, maintain just two option in nautilus default interface.

        Show internal partitions in left bar should possible activate in preferences too.

        Using search, if set for search only in folder, one line show information searching only in this folder, but don’t show one button or checkbox for change this, is much more simple add recursive option for change always user need.

        Nautilus is good, but simple interface improvements make very much better for me and lot people.

      2. it’s this kind of project folders where miller columns work very well imho to get a clear view of some subfolders. I would be very happy to have that view in Nautilus. +1 for the idea!

      3. yeah, I have considered in the past since it’s hard to come with an alternative in the current workflow. But the points before mentioned still stand… you could add some use cases and though in this and add it to as a feature request.

  5. Apple as good example? You must be kidding 😀
    At least they reached the level of “tabs” in their file-browser now, a decade after Nautilus 😉

    1. Actually, we take seriously any other file manager that is massively used and done by several UX designers in the trenches, even if we don’t agree with the design some times, would be silly to do otherwise! 🙂

    2. Finder (Apple file browser) has added tabs some 4 years ago, indeed it took them a bit longer to realize tabs on desktop are useful. From latest macOS it looks like now they took this approach further and have added tabs to every app (or almost every, not sure). I guess you must be kidding when laughing at the developers for making research on more advanced apps from other platform….sorry to say.

      1. No, I’m not kidding. It’s not about more advanced, it’s about other patterns and workflows. It’s unwise and uncientific not taking into account all you could (even to disagree) to make your app better.

  6. Thanks for your work, very appreciated 🙂
    Any chance some bugfixes (#777214 #777507 …) are backported to stable 3.22?

  7. I was wondering if development could pay close attention to profiling.

    I’ve switched to Thunar recently because it’s stupid fast.

    On the other hand Nautilus takes about 5 seconds to load my home directory while Thunar is something like 0.25 seconds.

    I would appreciate any attention or even the developers being mindful of this.

    (5ish seconds on a Intel i7-6700 :\)

    1. I might also add, could we please have folder icons rendered before thumbnails overlay them? Like a standard JPEG MIME Icon, etc…

      It really kills my workflow to navigate ALT+Up and by keyboard only to wait 1ish seconds on each folder for the thumbnails to render.

      This is on a SSD too, I can’t imagine the kind of hell I would be in on a 3.5 HDD, I shouldn’t have to switch to CLI Ranger or Thunar to get a speedy file manager in Gnome. Thank you for your efforts.

      1. hey, actually I didnt understand your issue. We do show icons for those while the thumbnails gets generated. What do you mean exactly?
        Also use bugzilla for bug reports, so we can track it (here will get lost)

    2. hey! Indeed it’s something we care about, but it’s hard when we don’t have the automated tools to do it properly. So there is actually an internship going to work on a profiling and debugging suite for Nautilus 🙂

  8. In the next release you really should NOT consentrate on creating new features etc. You REALLY SHOULD consentrate on making Nautilus and Gnome in general work with Orca screen reader. That is extremely important for the blind people like me. Currently Nautilus and Gnome in general is full of accessibility problems when used with Orca screen reader. Also note that blind and other visually impaired people use the computer board without using mouse. It really is not possible to use mouse if you are blind. So everything should be accessible from the keyboard and keyboard shortcuts are wery important. Userinterface MUST be designed so that it is easily accessible using Orca screen reader and keyboard ithout using mouse at all. Also note that animations, pictures and icons tell nothing to people who can not see. Every button etc MUST HAVE text label which Orca screen reader can speak to user. I IS NOT ok that user interface has buttons which have just icon and not text name at all. In those cases Orca screen reader says just”Push button” that tells nothing to user, it is impossible to know wht button like that does. Next time you realease something please test first theverythingworks with Orca screen reader and everything is accessible from the keyboard. Every component in the user interface must be accessible with Orca screen reader and every component must be accessible using keyboard without using mouse. I am not now talking about Nautilus only. In my opinion the whole Gnome desktop should consentrate on making the desktop accessible with Orca and keyboard. You should really forget new fancy features and make the system accessible first.

    1. Sorry for getting a late reply. This is very important for us, so please file any bug you find about that and we will take care.

  9. How about we revert the pie notification popup back to a small window (much like Windows Explorer and how Nautilus used to be)?? This would solve your issue of making the user aware of something happening and where to show it.
    Also – I couldn’t see anything in the roadmap for this, but add a way of clearing out completed file transfers? If you have lots on the go and keep them coming the list just gets longer and longer with no way to clear out the stuff that’s done.

    Another feature that was added (I forget which release and can’t find it in the release notes) is the single window properties dialogue. This makes comparing multiple files/folders within the same window impossible and extremely long-winded and frustrating. Have there been thoughts on user experience with regards to this and how that impacts user flow within Nautilus? A popup window (again like Windows Explorer and how Nautilus used to work) is much more flexible.

    1. Most of these issues sound rather off topic, feel free to create issues in for those.

      edit: Not as off topic as I though, I though it was a different blog post 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: