Nautilus 3.30

Hello all,

It’s this time of the year again, a new Nautilus release is on its way to be delivered. This release has been increasing contributions and work done in a steady pace as it has been for the last years, which makes me happy as one of the maintainers of Nautilus. This release had around 140 major contributions (merge requests) including whole features, fixes and improvements. Against our willing, we have included more code than deleted by 3000 lines πŸ˜‰

I will explain the most visible improvements and changes we have been doing as part of this 6 months effort. But first, a peek on how Nautilus 3.30 looks like:


New toolbar design

We have been trying to improve the exposure of available actions and make them available for the list view and for touch devices for over almost 3 years, iterating on several designs. We finally came with a solution that we are happy with. As a result the user can now access background actions in list view such as creating templates or extensions like opening in a terminal.

We also implemented a less cluttered path bar and moved the search entry to the same place to give more place for the actual content, the user’s files. Lately, we improved the usage on small resolutions making Nautilus be able to shrink up to 530px. The result is the following:

As part of the new design, we also replicated the app menu actions to the hamburger menu so it’s easily accessible in multi-monitor set ups:


The end result feels definitely more modern and implements one of the most requested features.

Dynamic space resizing

Probably everyone is aware that the code in the icon view of Nautilus is from 20 years ago when gtk+ didn’t exist, so it does everything manually.

One of the most obvious limitations was how the space was distributed between icons, it was not distributed at all and there was always empty space at the end. In previous versions it looked like:

Fortunately we came up with a solution for this release, with these results:

While the goal is to eventually move to a more modern code and use a proper gtk+ widget, this improves the situation until we can achieve that major goal.

Thanks Nikita Churaev for this work!

Desktop files aren’t special treated

When Nautilus had desktop icons we used to manage desktop files in a special way since the desktop was used as a way to launch applications. Last release the desktop was no longer part of the Nautilus code, so we could finally reconsider having desktop files as a special file to be launched or not.

The special treatment of desktop files had several problems, including security concerns (we had a CVE last year!) . Unfortunately the way we had to handle them was a blocker for the major rework of file operations that we are planning. This work will allow proper handling of files operations making them faster and secure.

The .desktop files are now treated as normal files: their real file name is shown and they open as text files in applications like GEdit. We leave their graphical edition to more featureful tools like Alacarte. We can provide replacements for some of their uses (you can provide use cases in the ticket). This goes with the vision of having a canonical path for trusting binaries and permissions rather than rely on Nautilus for such a delicate action.

CI/CD and automatic testing with Flatpak

CI in action

One of the major work this release has been around making the whole feedback cycle of Nautilus development shorter and make as easy as possible for everyone to test any change we do to give feedback even before the work is implemented.

As part of this, we have improved the experience of Flatpak with Nautilus, created a whole continuous integration (CI) and continuous delivery (CD) system with GitLab and Flatpak that automatically creates an app bundle, so anyone can install any work in progress of Nautilus with a single click.

An example of Ernestas work in gtk4

Going to any merge request and clicking the “View app” button will install a Flatpak app bundle where you can try the work in progress. A nightly of Nautilus that updates every day is also available in the GNOME Nightlies.

It has proven already successful with the toolbar redesign helping us getting early feedback and iterating on it. We hope that from now on everyone try the nightlies and engage with us on Nautilus development by either providing feedback, designs or contributing code.

Also, maybe it will come as a surprise, Nautilus didn’t really have automatic testing. To improve the situation we have invested 3 months on providing automatic testing to Nautilus. Now we have a full framework and batch of tests in the most critical parts like file operations and search. Automatic testing will improve stability and will avoid regressions reaching the user and has already made us find and fix several issues.

Tests running (and passing!)

Thanks Jordan Petridis, Ernestas Kulik and Alex Fazakas for this work!

Fast search of recent files

We have implemented a new search engine for faster results of user files that have been recently used. This will be an improvement specially for users in Ubuntu LTS that don’t have tracker installed and were used to search for files in the overview in Unity.

Thanks Marco Trevisan from Canonical for this work!

And more…

We have also work in many more details.

Only current folder searching

We have redesigned and added an information bar in case only the current location is being searched:


A detail to spot here is that Nautilus has the FTS feature which also takes into account the actual content of the user’s files for wider and better results.*

* Not available in Ubuntu

“Open in Disks” button

Advanced tooling for partitions and external devices can now be accessed easily in the properties window. Thanks Rahul Verma for this contribution!


Touch support for menus

Nautilus now supports popping context menus in touch devices by long pressing a single file or the view itself. This is another step on making sure Nautilus can be used with touch devices, as they become more relevant specially for business like design, sales, marketing and finances. Thanks Jan-Michael Brummer for working on this!

What’s next?

I hope you will be glad of this release, it has been a continuous effort of several people during 6 months, and we think it pays off!

While we fix the issues this new code introduces, we are already planning about the work for the next release. So what’s to come?

Ernestas Kulik is working (and sweating it) the port of Nautilus to gtk4. We have created a Flatpak nightly for testing, however it’s still very early and most likely will have major regressions. Our hope is to introduce gtk4 for Nautilus 3.32, we will announce the ready status for testing in the upcoming next 3 weeks.

Apart from that we have many other things, we expose our vision and planning for the project in GitLab. So go ahead and check what is going to come and provide input ahead of time to help us steering the project, check out the short term vision and planing, the long term vision and planing and lately, the vision and planning with possible user impact.

Thanks to all the contributors!


26 thoughts on “Nautilus 3.30

  1. Hello! Thanks for the work and overview. May I ask three things:
    Is find-as-you-type “only searching this folder” relying just on the local list of inodes assigend to this directory, or does it required tracker? Until now we have to open the preferences of Nautilus to switch between between “never” (find-as-you-type/his folder), “only this computer” and “all locations” – is this now possible without opening the preferences? Most of the time I’m navigating by find-as-you type, from time to time I don’t navigate but need to search a file and then I will have to open the preferences which is breaking the workflow.

    1. Hello Hoschi,

      Any search in Nautilus rely on four engines:
      – The current view cache (the fastest)
      – Tracker (second fastest)
      – Recent
      – Simple (crawling the filesystem)

      As per the “search only in this folder” is still a setting for the preferences dialog. If you want to find files in the current directory you don’t need this setting enabled, since those files are always shown first you don’t need to disable the search of the other files. Performance is not a problem either, since those four search engines are always ran in parallel. That setting is for those that for several reasons always only want to search in the current folder.

      Hope that answers your question!

      1. Hello Carlos! Thanks for the technical insight, that should be able to always return the required result and also quickly πŸ™‚

        Regarding the setting, I hope this is not to long for a small improvment:
        Phwolfer is also navigating by ‘type-ahead-find’, like me. So “Never” is always turned on which means for me ‘type-ahead-find’, therefore navigate quickly by keyboard.
        Sometimes I need to really search a file and then it is getting clumsy to switch it to “On this computer only” and back again to “Never”. Leaving it to “On this computer only” will present the local files as first, but clutters the windows with undesired results from sub-directories. May I give you an example of the workflow?

        I’m typing “util” to select (!= search) “util.cpp”:
        β€’ With “Never”:
        Nautilus selects the file util.cpp from in the current directory, done.
        β€’ With “On this computer only”:
        Nautilus will immediatley (the search is fast!) clutter the window with “util.cpp”, “”, “util.png”, “util” (directory) and so on and I have to think about which one is the desired file. In the icon-view I have to remember myself about the order, in the list-view the location is a visible hint.

        Because Nautilus is smart, we can also just enter a part of the filename, which is quite comfortable and improves keyboard navigation further. Let’s say the “png” (an application icon) in the current directory should be selected, which “On this computer only” to many more files on the screen than the current directory actually contains.

        You restored and repaired many well-known features during 3.16 and 3.18, if I recall correctly somewhere in this timeframe you have thought about making the switch immediatly available in the application window. That would be a little improvment again, it would allow for quicker switching the modes and make the current mode visible. Beause most of the time, I forget to turn off “On this computer only”.

        Thank you

    1. Hello Edna,

      That looks strangely odd, as in if a theme is missing. Can you provide the output of:
      $ flatpak list


  2. I have been using Nautilus on Fedora for three years now, after having used KDE for many years. Nautilus is simple and quite useful, but its usability might be improved with a few modifications, such as the two below:

    (1) An option for always showing file dates in full, and not just “Yesterday” or “Tuesday” if file dates are less than one-week old. It would also be nice to be able to choose between different date formats, such as “2018-07-28” or “28-Jul-2018”.

    (2) An option for selecting the font used specifically for showing file lists (I never use icons view). These lists look much better when shown in a monospaced font, such as DejaVu Sans Mono. File names would be more legible too, because in these fonts all characters are well differentiated (dotted zeros, uppercase “i” and lowercase “L”, etc).

    All the best!

    1. Hello Lemc,

      As far as I know, the problem with dates is that everyone wants it different, while we try to provide a sensible format that works for most people.

      A full iso date column has been discussed few times, I don’t know the reasoning of not having it apart of not respecting the user’s choice of date formats system-wise. As you might know, the format of the date depends on the formats you have configured in your system, and you can change that freely in the control center. If you find the issue at GitLab/Bugzilla that proposes an iso date you will see more context, I remember there was one. We could reevaluate its inclusion indeed.

      For the full “format date” configuration, it’s usually not a good idea and is hard to handle it properly. So I think we are more on the side of that not being part of Nautilus scope.

      Hope that clarifies a bit!

      1. Thank you for the clarifications.

        I often have to scan and check the dates/time on large lists of scientific data files, and frankly, it is annoying to see date labels shown simply as “Yesterday” or “Monday”. I tried to change the “Regions & Language” configurations in Gnome Settings (Fedora 28, fully updated), but this behavior remained unaltered. I would rather use Gnome’s native file manager, yet on these occasions I have to resort to Gnome Commander, which is way much more flexible on this regard.

        This default behavior of Nautilus is adequate for the average user, and my suggestion is simply to add configuration options under Nautilus’ “Preferences” to change the way date/time is shown. I believe this functionality would not be difficult to implement directly in Nautilus, or it might be added even as a gnome-shell-extension.

        All the best!

      2. I would be open to have a column with iso format, can you open an issue about this?

        What I consider out of scope (and the past experience confirms that this is a bad idea) is a date format editor.

      3. Surely a date format editor would be out of scope as far as Nautilus is concerned! I thought of something like you have in LibreOffice, which allows the user to select a date format from a list of pre-configured, fixed formats, when you want to insert a date field in a document.

        I will follow your suggestion about opening an issue.

        Best regards.

      4. I generally like how Nautilus displays the dates. But I would suggest to add a tooltip to the date column which displays the full date and time (in the user’s locale). The way dates are currently displayed helps me in identifying dates quickly, as it is a very human like of describing dates. But sometimes I need to know the exact time of multiple files, and going into each files details is annoying.

        I myself always try to follow the pattern to show the tooltip when I use abbreviated / more human speech like date / time information in my own applications. It is the same reasoning why e.g. the Nautilus sidebar also shows tooltips for the locations: Nice display to the user, but easily accessible detail when needed.

  3. The removal of support for .desktop files leaves Linux (or at least the Gnome desktop) without an application shortcut system. While I find it surprising that this was haned by the file manager to begin with, rather than some other part of the system, do you think it is a good idea to remove a feature like this that many applications and as such users rely on, even though there is no longer a desktop? Is it maybe to start work on some sort of unified shortcut support that is not dependent on the file manager?

    1. Hello robinj1995,

      What is exactly a shortcut for you? If it’s in the sense of Windows, doesn’t symbolic link works for you? What applications rely on desktop files used as “shortcuts”?


      1. It’s indeed typically in the sense of Windows to launch windows application through wine :-), it may not be the only way but that’s clearly the easiest as the shortcut is automatically created with the setting of the prefix and so on

  4. Regarding the Nautilus update, thanks a lot for the overview and thanks even more for the work done on development, a lot of nice improvement to an already great application !

  5. My main problem with search is still that there is no easy way to toggle the recursive search. I know we already had a discussion about this on Gitlab, but in my daily work I frequently find the search less useful for me. I often just want to quickly filter the current folder view to quickly find what I am looking for, unless I suddenly want to search for a specific file that is hidden deep inside a folder hierarchy.

    The first use case is basically what the old “type-ahead” search also provided. This needs the recursive search disabled. The other use case is the typically deep search that needs recursive enabled. No matter how I set the preference, it will be wrong the next time I want to search.

    I think having a toggle to quickly switch between recusrive and non-recursive search would also help some of the people who miss the old type-ahead feature.

    1. Hey phwolfer,

      Probably I asked the same questions as before then, but let’s try.

      Why do you need to change that setting? Search works in the current directory too, and it puts the files that are from the current directory first separated from the others by the “Location” field.

      The performance is almost exactly the same, since those files comes from the cache directly regardless of whether that setting is enabled or not. The only overhead is that we create 1 thread more.

      1. I find this full result list still very cluttered, especially with many results in large trees. Instead of seeing a limited list with the results I care about I see everything. Also sometimes I do recursive search on non-local folders, where it is disabled by default.

        In this case it is an improvement you show the notice now that only the current folder is searched, so at least I get informed how my settings are. But as a user when I see this info and I actually want to do a recursive way I miss a quick way to change this. It is a bit annoying when you are told “only the local folder is searched” without a way or at least hint how to change that.

        About the new version: I gave the development nightlies a try and I must say I really like the new additions, the new toolbar is great!

  6. Hi Carlos, would you change the `Only searching the current folder` phrase to `Only searching the /home/user` or something to indicator current folder name? since it’s hard to get this info when search with the path bar.

  7. Hi Carlos,

    there are some really great changes and all-in-all Nautilus is one of the most complete filemanagers at all. – Thanks for this.

    But I’m still missing some functions, the “OLD” nautilus had (and I mean really old):

    – setting own formats for columns in the ListView, for example owner/group and time/date
    – having a tiled layout like gnome-commander

    Do you see a chance to get this back?

    1. Hello Tim, thanks for that feedback! πŸ™‚

      Probably you used Nautilus and know more about its history than me then πŸ˜€

      Unfortunately none of those features are in the roadmap, we are trying to focus a lot and make sure that what we have is valuable and works well, so streamlining it more than adding new things. For the upcoming two years we are focused on just two or three things in total. You can take a look at our roadmap here:
      – Short term planning:
      – Long term planning:

      Hope that’s useful!

  8. Navigating (which is something different than searching) by type ahead is essential to me and many others. This has been discussed a lot and I am disappointed that it is not considered. I won’t use any unpatched version of Nautilus until there is at least an option for that…

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: