Nautilus 3.20 – Last change, Zooms


We did a last push and hold the release a week to get another of the items that were requested.

We added a new zoom level to nautilus, now you will have available 48px, 64px, 96px and 128px.

This was hard to do because of how the canvas of nautilus behaves, which multiplies the padding according to the zoom level. So we cannot control the padding, making the view unusable on zoom levels farther than the range 64px – 128px.

With a big effort of the previous main maintainer Cosimo Cecchi who we asked for help, and the design review of Allan, we managed to make the change preserving the padding for  zoom levels but improving the sizing of the label and thumbnails. So we effectively didn’t introduce any change that could affect previous users.

This was important since we tried different approaches during this last week and those made different types of users complain about the changes. Surprisingly to me, now lot of people are attached to the 96px zoom level that was made default for 3.16.

We will rethink the use cases of those views and we will work further on it.

However, the canvas of nautilus needs to be completely rewritten and we cannot do anything more with the current code without spending valuable time in that tricky and old code. I hope the week we spent on it worth it.

This is how the default zoom level padding thumbnails improved:





You can see the difference of thumbnails showing more content.

And this is the smallest zoom level added:


Have a nice day


Nautilus – Looking into 3.20


3.20 it’s approaching, and we have mostly all the changes we wanted in place.

I would like to explain them, so you are aware, and I would like you to test them and provide feedback before the UI freeze this week. So now it’s your time to change the way Nautilus will look and work for 3.20 and improve it for all us to enjoy it.

So what did we do this release? For me personally, I mostly focused on fixes, because during 3.16 and 3.18 lot of changes made in, but it was time with all the experience I gathered to start fixing old and hard bugs. Some of that work is uninteresting for most of users, because they are use cases that are no so common. But still, Nautilus is used in lot of different ways with very different workflows, and I wanted to make sure those workflows were working properly.

Under the hood

As a example of what we fixed is for example this bug about big images (specifically jp2 images) crashing nautilus, and that took me a week working on it. This bug was in nautilus since….forever.

Also, we fixed cases of infinity waiting on search, and spent quite a bit on time on making search more robust making sure the search is cancelled when the users says, making sure we do tied operations at once, or allowing a search being in the history so you can return to it using the arrows in the toolbar.

Other under the hood fixes include showing the free space in the other places view, the “New Window” action in the dash, undiscoverability for the operations popover (although not in the best way we wanted).

Also, since the desktop (edit: Since there was some confusion, I mean the icons on the desktop which we disable by default in gnome-shell/nautilus, not the desktop as a concept) is still important for some users, few issues were fixed like the snapping of the icons,  the misalignment of the renaming popover (Thanks Ian!), or the style of the desktop window (Thanks Alberts!). And more improvements in this topic are going to come.

Another point we tried this release is to make sure we care about the distributions using Nautilus, and we tried to fix most of the bugs reported as a blockers for Ubuntu or Open Suse in time for their deadlines. Of course, since I personally use Fedora, and as part of my job, RHEL blockers and Fedora retrace website were my main focus for the most prominent issues.

Ubuntu developers contributed a few patches for Nautilus, and I’m looking forward to see the result of our work in their distribution.

On the other hand I spent almost a whole month working on leaks and ownership in Nautilus, which is the most difficult issue in it, because any file leak means a crash or misbehavior later on. So we refactored, improved and modified lot of code inside Nautilus, and I’m happy I reserved the time and energy to work on it.

But now to the most enjoyable part, the UI changes.

UI Changes

Felipe Borges (thanks!) provided Nautilus with a shortcuts window, so now you can know in a quick look all of the Nautilus shortcuts. The final result looks like:



I’m excited we finally have this! No more digging through the code to find them…

We added a few options to Nautilus preferences, due to either not having a good alternative to them (create link for files, thanks Razvan!) or because sometimes simply there are too different use cases to merge them together (delete files bypassing the trash).

The result is:



And finally, the biggest change of this release. The new search popover UI, designed by Allan Day and implemented by Georges Stravacas (aka ubiquitous code machine)!

We still need to discuss some more functionality in the mockups, but the most important functionality is already there.

This is the result (Note that the style and colors is still under progress and have some issues):


Then we click the “Select dates” button and…


Now you can filter by time the file was either last used or last modified!

But not only that… how about if instead of “since 1 week ago” we want to filter for files modified on a specific date? No problem, we click the calendar icon and we get:


And here you can select the specific date.

What about filtering by type? Now we can do that, select the “What” you want to search for, the result is:


And you can search for any type of files you want. Let’s create an example. I want files that are PDF and that were modified the last week. Let’s select the filters and we get…


Ta-da! We also have the entry tags to provide feedback about what filters are on in case the user close the search popover, and you can remove them clicking either in the popover or in the close button inside the tag.

So far, for me this is much more convenient and powerful than the previous search, and finally we can kill the myth about not adding features to Nautilus 😉

On the other hand, we had a sad history regarding recursive search, we were not performing recursive search in remote locations, but we didn’t provide any option to enable it, and vice versa for local locations.

We wanted to improve this situation, so as a first step we created two different settings, one for the remote locations and one for the local locations, so the user can make a choice on performing a recursive search independently.

For the UI, we first implemented this as a switch in the search popover.

However, in my misunderstanding, I though that switch in the search popover was the representation of the setting itself. That means, whether you change that, it will make the choice permanent for the type of search you are doing (remote or local). But designers corrected me about it, the search popover is meant to be temporary, the filters about dates and types are temporary, and therefore any element there should be temporary. So that brought me to a difficult choice:

  • We add the switch to the search popover and any change there will be just temporary to that search, expecting the user to expect the recursive tool to be most of the times a temporary choice or…
  • Add a settings in the preferences dialog and make the setting permanent, expecting that choice to be persistent through future searches or…
  • Both of them.

However, a similar decision kicked us previously…. with the view settings. That is, the choice of whether you are using the list view or the icon view, or the sorting of the files, whether you sort them i.e. by name or by size.

Before 3.16 any choice in the view menu was temporary, however users were confused because they changed the view type or the sorting type and the next time they open a directory or create a tab or a window everything was reset. We received more than 10 bug reports about that while I was working for 3.16, and I had to point them that those settings were temporary and that any permanent settings is in the preference dialog. Needless to say, they were confused, frustrated and angry about it.

So I understood that was not a great choice and moved everything on the view menu to be a permanent setting, and luckily that worked and didn’t received any more bug reports about it or against that change.

Thing is, with the recursive search is even more important, because seems that’s a sensible topic for some users, and what we need to avoid is making those users confused and frustrated about the recursive search setting being reset every time they perform a new search.

So in order to avoid that I took the safest path and removed the switch from the popover and added a settings in the preference dialog. This assumes that the most usual workflow is to make a permanent choice about if you want recursive search on local or remote, because either your hard disk or internet connection is fast enough to perform a successful and fast search of the file the user is searching for or is not.

So this is the result in the preferences dialog:


In others news, I’m quite happy that Nautilus continues to attract newcomers to its development, and they are making a great difference on it.

On the other hand I want to thank all the people involved in this release and those who helped me with it, and also my employer Red Hat and Jiří to give me the freedom to work on what I consider important.

And that’s the major changes we did for 3.20, hope you like the work!

PD: To safely test this and provide feedback you can use Gnome built iso images which are a live system built every day from latest Gnome. Check it out.