Nautilus 3.18 – Comunicating changes

Hello community,

So these 3 weeks has been crazy of work. Basically because we had a roadmap, and we wanted to complete all that was marked as a target. The UI freeze was the first deadline, and Georges (Gsoc student for Nautilus and Gtk+ that I was mentoring) and me managed to get merged the Other Locations view, as Georges did for Gtk+ previously. Was a overworked week and a half, but the result came in!

So important changes on 3.17.90:

Now we use a popover for renaming instead of a dialog, since some users gave valid reasoning for it and designers also though in the same way after testing for a few days. Good thing is that a popover allows us to provide the same kind of experience than a dialog but being less disruptive, so I think it was a good change.


Then we have the other locations view, which aims to replace the connect to server dialog and provide a cleaner experience. We invested lot of effort on this one (Georges the most of course) and I think the overall result is really nice.

other-locationsAlso we improved the operations feedback, and now the button tries to catch more attention and also the operations give feedback much sooner.


Also we improved the search, making it faster (tracking races, not internal rework) and making the files of the current folder easily recognizable. When you search, the view switches to list view to allow the user see more information about the files, being the most important the location, so he can discern between file names that are duplicated. If the user changes the view manually, we disable this automatic behavior. Also, files on the current folder are always first, and files on the current folder don’t show a name in the location columns, to make it distinguishable from other files at first look. And another small improvement… now the location row show the relative path to the original folder of the search. So no the full path, which is too much and disruptive, neither only the containing folder, which is too little information.

Also we disabled manual sorting on Recent and Search to avoid confusion using a different sorting on those. Maybe we will need to think about search, because one might want to search but sort in a different way. However, maybe we can do that differently? It’s an open question, but for now try to avoid inconsistencies.


Also, the preferences dialog went down considerably…but not because we removed them, but because now all the settings are in-window! Previously people were confused about having permanent settings on the “Preferences” dialog, and temporary (and it actually depended on what!) preferences in the menus of the window. So now all menus of the windows are permanent preferences.

Major changes for 3.17.91

We did lot of ground work to clean up the code… because it was somewhat confusing, and actually the isolation of components were null. That was kinda on the way to have more kind of views, like the other-locations one. Georges isolated the necessary to make it work, and after his work was merged, I took the remaining part.

It was a hard part, and dealing with races on multi-thread as you may know is the worse debug process. But it is necessary for the future rework of the views planned for 3.20, and to be honest, nevertheless Nautilus just really needed that.

Also we fixed most of the translations problems of Nautilus thanks to Alexandre Franke and Piotr Drąg.

And actually I want to do give some special thanks to Piotr to spot in a matter of minutes any translation problem, and not only that, but fixing the code by himself (and adding the files to POTFILES that it’s something that I always forgot). So kudos to you!

Also we added a preference disabled by default for the “automatically open folder after a timeout while performing a drag and drop operation and hovering a folder”, since performing actions while the user is still, and keep doing it while there is folders available, it’s not a really good experience. Also actions based in timeouts are even more problematic for people with disabilities. But the real reason to actually take the decision is the possible consequences. Since the action can be performed accidentally, it can happens that the user lose track of where he was, and drop files in a place that he was not expecting to, losing the track of his files. Another example, is dropping accidentally sensible files on a public folder.

However, I learned that is the kind of feature that some people were happy to use as is, and even if its implementation doesn’t comply the standards, it was already there and some people were used to it. That’s why there is a setting to allow those users to enable or disable at their will.

Another point, now we take care about remote locations for searching. It won’t longer try to make a recursive search making everything slow and consuming a big chunk of bandwidth. Also we provide feedback about that when searching on those cases.

non-recursive-searchThings that need work:

There is a problem though, with all the ground changes we took the risk to be more unstable than we are used to. So now I fixed the most important crashes, but there is still work to do and we need testing. I hope everything will be better for 3.18, but being honest, I actually expect that 3.18.1 will be as stable as 3.16 was, but 3.18 will have small issues.

Another issue, even if we improve the search, I made it worse in the latest days due to the need of peeking the file system information for deciding if the location is remote or not. However I already have a bug report for that and I will track it hopefully before the 3.18 release.

Also, if you want to know the most important changes, they are kept track of them on the NEWS file and for future, you have the roadmap in the wiki of nautilus

Hope you like what we have done for this release. Was hard, but we were passionate about it and we are happy the result is there!

Thanks to everyone who made it possible.

PD: I will continue the series of blog posts about what was discussed at Guadec.


50 thoughts on “Nautilus 3.18 – Comunicating changes

  1. one thing which always bothered me when doing file renames: If I enter an invalid character (e.g. ‘/’ in Linux) I have to retype the complete path again. Ideally I’d see which characters are invalid and get the chance to correct them without typing all the other stuff again.

    1. I think I’m missing something… we implemented the popover just because of that, to allow to show incorrect paths. Did I miss missing on your comment?

      1. bonus points if you highlight invalid characters with the error style class as-you-type 😉
        (or at least i think that could be cool and super useful)

      2. It probably shouldn’t let you type in characters like ‘/’ in the first place – and if they do get in, e.g. via paste then have something like a squiggly underline ?

      3. I still do not understand why you decided to kill inplace renaming. (Ugly code – ok, but that can be rewritten.)

        Maybe I just can’t find where you (or other devs) stated the full reasoning, otherwise please do that at some point – not least because I’m sure this will draw more heat when the 3.18 is released.


        1. Why not leave inplace as it was and simply put the feedback (invalid new name, etc) in a popover that only appears if needed?

        2a. What advantages over 1. does moving the entire process into a popover offer?

        2b. AFAIK no file manager, esp. none of popularity, decided against inplace, and I’m sure it must have occurred to Apple, Microsoft & co. So if there are any advantages, what makes you think they are worth the added disruption?

        3. What about long/growing filenames and (list view) wide windows?

        4. (Also list view) I see you changed the popover location to where the cursor clicked in a recent commit. But what about people who use the keyboard for navigating, ie. when no such position is available?

      4. To Djan (since wordpress doesn’t allow three deep replies):
        “Maybe I just can’t find where you (or other devs) stated the full reasoning, otherwise please do that at some point”
        In a post in this blog, in the commit message when the change was made and in the release notes. Where else can I post the reasoning about it? 🙂
        “1. Why not leave inplace as it was and simply put the feedback (invalid new name, etc) in a popover that only appears if needed?”
        Appearing and disappearing popovers is more disruptive. But the big deal here, inline renaming is not touch capable.
        “2a. What advantages over 1. does moving the entire process into a popover offer?”
        Permanent layout, touch capable, flexibility to changes.
        “2b. AFAIK no file manager, esp. none of popularity, decided against inplace, and I’m sure it must have occurred to Apple, Microsoft & co. So if there are any advantages, what makes you think they are worth the added disruption?”
        I dont know this one.
        “3. What about long/growing filenames and (list view) wide windows?”
        Reported and known bug. Looking for a solution.
        “4. (Also list view) I see you changed the popover location to where the cursor clicked in a recent commit. But what about people who use the keyboard for navigating, ie. when no such position is available?”
        Reported and fix available.

      5. Thanks for the fast reply. It’s good to hear that these issues are known and getting worked out, because that popover sure still needs the visual streamlining. (After which I can probably make my peace with it :))

        Two more thoughts:

        1. There’s no real need to fatten the popover with “File name” at the top – the user explicitly calls rename and the form itself makes it even more apparent – and with an equal amount of useless space at its bottom.

        2. The “rename” button is really wide, esp. with a user locale that maps to a longer word. Maybe use an adequately sized “✓”?

        1. and 2. currently mean that the actual input field occupies only a little more than a sixth of the popover for me.

        One final remark…

        “But the big deal here, inline renaming is not touch capable.”

        I don’t see why not, in both cases you’re calling rename the same way and entering an input field. Unless you mean it’s a code thing; it’s certainly easier to maintain one-size-fits-all code that assumes that every user group has the same requirements/ergonomics. Which is hardly the actual case though.

        (Re. 4.: But there’s no fix committed yet?)

      6. 1- It isn’t, we did it to maintain layout consistency for the warning label that is below the entry. Basically it looked odd.
        2- We tend to use words for actions. Probably the HIG explains why and when use icons or words. I just followed the design, so I can’t explain.

        Inline renaming is not touch capable -> Imagine how it woukd work. How do you cancel? how do you accept? how do you prevent unwanted cancelation or accept?

        re 4 -> fix no commited, it’s in bug report and Im holding the release until i have time to review, fix, and merge.

  2. That popover looks like a place where some transparency would not be a bad thing – with a little, you’d be able to read the “showcases” and “” that are under it a little better.

    1. Transparency is most of the times a problem, and even more if there are characters behind, which is the actual case…. I think saying as a feedback that there is already a file named like that is what covers that case.

      1. Yeah – transparency is probably not the answer. I was thinking of the case of typing in a name that is similar to another file in a directory, e.g. Slightly-Obscured-Filename-2.txt

  3. On search – being able to change how it’s sorted is definitely useful. You’re right it could do with some thought – while alphabetical makes sense as a default, it be confusing if it always revered to alphabetic on a new search ?

    1. It’s not alphabetical, is by “search relevance”, so files on the current folder are first, names that match better the name are first, etc.
      I can think that the real use case here is by modification. So files that match expenses-report- ordered by modification date. But I think this is actually an use case for filters instead of sorting

      1. Switching between orders in results can be useful – for instance you are looking at backups or copies of the same folder and might try ordering switching the order to size or date to work out which is correct.

        As long as change the filters is instant I guess it doesn’t make too much difference (which it should be if on the same search ?).

    1. A notification is shown, the operation keeps going, if you click the notification it opens nautilus window, and if the operation finish while close a new notification is trigered showing feedback about which operation was finished and showing actions like “Show files” or “Ok”.

  4. The rename popover doesn’t seem to work very well for medium to long filenames. The rename field has fixed width, it does not expand nor horizontally nor vertically, the text is not wrapped to be visible. So if you want to rename a file with a bit longer filename (let’s say “Fedora-Workstation-netinst-x86_64-23_Alpha.iso”, and that’s just a simple example, I have many files with much longer filenames, i.e. with timestamps), you see just a part of it in that text field, and you need to constantly scroll left and right to make sure the new name looks correct. In this case the new popover is very unpleasant to use. With the previous UI, I always saw the full name and could navigate the cursor and edit any part of it without losing the overall picture. Now I have a feeling I’m looking through a keyhole. Can this be improved, please?

    I’d make the field multiline, and expand it horizontally and vertically dynamically to fit the whole name all the time. The maximum filename length under Linux is 255 characters on most filesystems, so it shouldn’t get out of hand.

      1. Indeed, but for a technical issue we cannot. We need to rework the whole views… luckely it’s planned for next release or the next if nothing comes up

  5. I have just tried nautilus 3.18. There is one very annoying inconsistency. With each version of nautilus creation of an empty file in a folder becomes increasingly difficult, or even impossible in list view mode. If you are lucky and you are in a folder where the listed files/folders fit well inside the view height, you can then right click on the remaining whitespace and create a “New Document”. If there is no whitespace, in nautilus 3.16 one still had the possibility of clicking on the “Location options” button in the toolbar and choose “New Document” there. In 3.18 this option seems to be missing, so the only remaining workaround is to switch to icon view, create the document and switch back to list view. Please add a dummy line at the bottom of the list so that the user at least has a white space independent of the number of files and window height, as suggested e.g in
    It is not consistent that the interaction of the user with nautilus depends on the number of files in a folder and the presence of whitespace. Either the white space should become not clickable, even when it is available, or there should be some guaranteed whitespace available (e.g. by having a dummy line).

  6. Curious is there any news/plans to fix navigation (ie. typeahead).
    I’m currently stuck at gnome 3.4 with wheezy, as I get major disruption when I try to use anything later…

    I know I’m not the only one… And to be honest I gave search a fair try, but I keep opening random files and folders when I try to open things without using the mouse…

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 )

Google photo

You are commenting using your Google 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