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 🙂

Core Apps Hackfest – A success!

The GNOME Core Apps Hackfest just finished, I’m happy to say that it was a success!

Many people from different backgrounds were able to come, either from the community or from companies like Red Hat, Endless, Kinvolk, etc. all of us involved in different parts of the GNOME project.

The first we did was to write down what points  must be discussed during the 3 days, along with identifying the people involved in those topics. This was the trick to be productive in the hackfest, and all of us agreed it worked.

first day hackfest.jpg
First day early in the morning, before all people joined
IMG_20161127_175628.jpg
Roadmap for the hackfest

Since it’s hard to see what’s written:

  • Tracker
    • System vs apps (containerisation)
    • Performance
    • Removable devices
  • Maps
  • Usage app (one  is being created)
  • Control center redesign
    • Network panel
    • Details panel
  • Calendar
    • Week view
    • Recurring events
    • Location checks/sugestions
  • Books
  • Software
    • Categories
    • Offline experience
    • Rollback
    • Shell extensions
    • Performance
    • Flatpaks installation
    • System vs user installs
    • EULA/Licenses
  • Sharing portal
  • Content selection portal
  • Libgd
    • Flowbox view
    • Tagged entry
  • Background apps
  • Files
    • Action bar
    • Bookmarks / XDG folders
    • External devices
  • Opening files with content apps
  • Extras
    • Music
    • Videos (series view)
    • Newcomers initiative, new revamp planning

Quite a lot! From that list we identified the most important items and the optional ones that are short enough to allocate some time for. We also identified which items require the most amount of people from different backgrounds to be together so they can be handled as best as possible.

Some topics were very well covered. GNOME Software is now important for a few companies and distributions, so it took quite a lot of discussion during the hackfest . Another topic that was discussed extensively was opening files with content applications, basically using Music, Photos, etc. to open files from Files.

But we also discussed more technical items, thanks to having gtk+ maintainers in the hackfest we were able to talk about gtk4, it’s new OpenGL based drawing model, containers API, GtkListBo, GtkFlowBox and essentially all what we need for our applications and 3rd party developers in the upcoming months.

Some of us will write about the specific items in the upcoming days with blog posts, so keep an eye on planet.gnome.org to see all the discussion we had and what solutions and decisions we came up with for those.

I want to say a big thank you for the excellent organisation of Joaquim Rocha, and for hosting us to Kinvolk, especially to Chris Kühl

kinvolk_logo

and Collabora for sponsoring an excellent dinner on the first day of the hackfest

collabora-logo-1

We had a great one!

DSC01798.JPG
Relaxing a bit in the Collabora sponsored dinner

Also to Red Hat and Endless for sending quite a few employees, and last but not least, to the GNOME Foundation for sponsoring the community members, who were essential in our discussions.

Hope you had fun!

GNOME Core Apps Hackfest – Sponsors

As I mentioned in my previous blog post we organized a hackfest to discuss all about the core GNOME experience, with emphasis on core apps and taking into account its impact in 3rd party developers too.
But you can imagine, bringing together a not small amount of developer, designers and community in a single place involves travel costs, accommodation, an appropiate place where we can gather and discuss with internet and tables… and apart of that, small details that improves the overall experience like snacks and something to distract ourselves after a long journey, like a simple dinner all of us together.

This is not possible without the GNOME foundation and companies who believe this is important enough to sponsor people going and the organized events.
In this post I want to announce and thanks the (so far) two sponsors we have got already!

The sponsors

Kinvolk folks will provide us the venue and snacks every day, thanks!

kinvolk_logo.png

Collabora will provide us a sponsored dinner the first day, thanks!

Collabora-Logo (1).png

 

And of course thanks the GNOME foundation and Red Hat who will help a big part of travel and accommodation costs.

Hope to see you all there!

GNOME Core Apps Hackfest

It’s official now, we will have a GNOME Core Apps hackfest happening in Berlin, Germany on November 25-27!

tour-berlin-shore-excursion-1-day-2.jpg

The hackfest is aimed to raise the standard of the overall core experience in GNOME, this includes the core apps like Documents, Files, Music, Photos and Videos, etc. In particular, we want to identify missing features and sore points that needs to be addressed and the interaction between apps and the desktop.

Making the core apps push beyond the limits of the framework and making them excellent will not only be helpful for the GNOME desktop experience, but also for 3rd party apps, where we will implement what they are missing and also serve as an example of what an app could be.

In case you are interested, here is the wiki page with more information. All of you are welcome to attend.

Thanks to Kinvolk folks that will host us in their office!

Nautilus 3.22 – News & Changes

Nautilus 3.22 is reaching it’s final phase, and as I have been doing in the past, this post will explain what new tools and improvements we worked hard to implement, what changes to expect, and what we couldn’t fit in. I need to confess I’m excellently amazed with this release, it has so many new things that I’m proud to say this is the best release we did of Nautilus since I became maintainer. This is possible thanks to all the underneath work we have been doing, and sometimes this requires the removal and re-implementation of some tools in a different form.

News

Lets take a look what we included in this release

Multiple Files Renaming

For some time users of Nautilus lacked a tool for rename multiple files at once. We relied on external tools or command line utilities. It’s true that other file managers had utilities for multiple files renaming for long time, including Finder from MacOSX. Thing is we weren’t happy with how those worked and the experience they provide. So we designed and put lot of though on making, in my humble opinion, the best batch renaming tool we could have.

We allow to use the metadata of the files when available, which is for me the biggest win in our tool. I’m happy I could rename all my music files using the track number, album name and track name. Same for TV shows, where you can add the season and episode. And for pictures, the camera and the date taken.

A picture worth 1000 words

Search & Replace

batch rename3

Rename with a template & metadata of files

batch renaming1

Conflicts handling

batch renaming2

And a real use case

batch rename music

Finally my music library renamed with the same pattern! I think you will agree with me this is pretty amazing. Thanks Alex Pandelea for this work!

Compressed files integration

You may be aware that we have been using File Roller since forever to handle compressed files. However, this makes integration with Nautilus none. It misses the progress report integration, undo, redo, and possibility to close the application while the operation continues. Finally we tackled this, it was a big amount of work where we needed to create a new library to handle compression and decompression in a way that can be integrated with Nautilus and other GNOME projects. For instance we would like Evolution and Epiphany to automatically compress/decompress archives on upload/download. Using this library, called gnome-autoar, is pretty simple.

Again, a picture worth 1000 words, let’s look at compression dialog

compress window.png

We provide a sensible set of options. Now let’s take a look at compression progress integration.

compression.png

We finally have status report, undo, redo and operation integration like any other Nautilus operation!

The same applies for decompressing. Overall, this is something we have been pursuing for years, and the output is pretty cool. This allows us to finally be able decompress archives by default when double clicking on them, so the user doesn’t need to handle compressed archives, which usually provide much less information like thumbnails etc than a regular folder. In case you still prefer to use file roller or any other application by default to manage your compressed files, we added a preference in the preferences window.

Here you can see the option “Extract the files on open”preferences.png

Thanks Razvan Chitu for this work!

View menus

As you may be aware, we perform user testings regularly. In the last user testings  was found that the view menus of Nautilus had some issues that could be improved for a better UX experience. The design team put some though into it and came with a design that fix these issues, and Neil Herald implemented them. Here are the results

menus.png

Now the grid/list button changes between the two kind of views, and we merged and improved the hamburguer menu to include all the options we wanted. The zoom slider was one of the most fails in the user testings, so we took a similar approach of what Firefox has.

I’m quite happy we fixed the user testing issues we found every release!

Separate desktop handling from Nautilus

There are two monsters on Nautilus. One is the operations handling, the other, the views.

Since I became maintainer of Nautilus my top goal was to re-implement the views of Nautilus to provide what we should have in a modern file manager. This requires an amount of work unimaginable, and part of that is because Nautilus handles the desktop window, which is made by several amount of hacks all around Nautilus to make it work. This needed to be split before any work can be started on the views part, and it is not easy. We started one year ago, and I’m happy to say, this release we finished the work on the Nautilus side, separating the desktop program and code from regular Nautilus. Now if the desktop crash, Nautilus won’t. This allows us to finally implement a modern and responsive view for your files!

This is a peek video at the view I prototyped thanks to this work

 

However, this requires also work on Gtk+ for improving the performance, which is what we are going to try to tackle next release. More than half step is done!

Better folder creation from selection

This is a small touch, but I think worth mentioning. When selecting multiple files and creating a folder with them, we will search for a common prefix and use that as default name. Here is a picture

new folder

Thanks Neil Herald for working on it!

(Updated, I forgot!) Hide floating bar on mouse hover

The floating bar is what is shown in the rightmost lowest corner of Nautilus with information. However, that can get in the way if the information is displaying is long and obscures the actual content of the view. For that, we implemented a new behaviour that makes the floating bar disappears if the user hovers it with the mouse.

with floating bar
Mouse not hovering floating bar
withouth floating bar
Mouse hovering floating bar

What we couldn’t include

As always, we want to put into a release as much as we can, but we are still humans 🙂

There are two important items that weren’t possible to include in this release.

Action & Info bar

One is the action-info bar we have been experimenting with. We didn’t include it because we weren’t sure about the design and implementation. However we can peek at the prototype

action bar.png

We will continue experimenting in the next release.

Thanks Georges Stravacas for working on it!

New Path bar

The path bar is the widget in the top of the Nautilus window that shows the path, and allows to interact with the hierarchy of the current folder where the user is. We have been trying to update it with a more sane code and elegant design. I have been working on it and iterating through almost 4 different designs for one year and a half.

After all the experimenting, we finally decided on a design!

pathbar.png

However, there are technical limitations in the Gtk+ toolkit for make it work in the way designers imagined. So this has been an experiment for me and towards Gtk+ to push its limits. Finally I found a way to make it work, but all the nice projects I mentioned previously came in.

I’m sad I didn’t manage to include it in this release. On the other side I’m happy that we have a prototype and that we will have more time for testing and reviewing.

If you want to take a peek, here is a video demo

Wrapping up

There has been a lot more into this release, from small tweaks to big refactorings and bug fixing. We even created a single code style for Nautilus (it had a mix of 3 styles) and (be careful it might crash your browser) changed all the files to it, which was a demand from all the regular contributors. (edit: please don’t argue about this, the style is agreed by the ones that work on Nautilus every day that makes our performance and life better. Just a matter of practicity. Nothing more, nothing else 🙂 ).

old_style
Old style
new_style
New style

For this release we have around 900 commits and five regular contributors, which I want to thank one that has not been mentioned here, but it does all what we really need in the places nobody dare to, you rock Ernestas Kulik.

If you want to try last version with updates every day and parallel installable to not affect your installed Nautilus, take a look at the Flatpak installation of latest Nautilus.

Hope you like what we have been working on and enjoy it!

The future is here

To see the future, run in a terminal:

$ wget https://sdk.gnome.org/nightly/keys/nightly.gpg
$ flatpak remote-add --gpg-import=nightly.gpg gnome-nightly-apps https://sdk.gnome.org/nightly/repo-apps/

$ flatpak remote-add --gpg-import=nightly.gpg gnome-nightly https://sdk.gnome.org/nightly/repo/
$ flatpak install gnome-nightly org.gnome.Platform master
$ flatpak install gnome-nightly-apps org.gnome.Nautilus master
$ killall nautilus # No running instance has to be present
$ flatpak run org.gnome.Nautilus

*for Ubuntu look at the end of the post.

Results in:

nautilus-flatpak.png

Nautilus from master, updated everyday, parallel installable, in less than 3 minutes. I cannot believe this is possible. Note that due to be sandboxed with no permission handling there are things that are not working, like opening with an application.

For someone not aware of the whole platform and the Linux desktop, it’s difficult to see how many implications this bring to us and the changes that will allow in the upcoming months. This truly changes the game for GNOME (and any other desktop) as a project and platform, including 3rd party developers and companies using Linux desktops or that want to support it.

Amazing job Alex Larsson!  Flatpak is the big step we needed.

In case of using Ubuntu, flatpak is still not in main repositories, it should arrive soon. In the meantime do:

$ sudo add-apt-repository ppa:alexlarsson/flatpak && sudo apt update && sudo apt install flatpak

And then run the commands at the start of the post.

Contributors to Nautilus

At GUADEC Andre Klaper made a report of top most contributors to GNOME in the last year, and to my surprise I saw my name in the top 5 of patch reviewers. Did I really review so many patches?

If you remember I did a blog post stating how healthy Nautilus development is being lately. However I didn’t know it was at this level. And now I also understand why I spend less time coding these days.

To summarize, the first year as maintainer of Nautilus I reviewed around 100 patches in total.

And this is how it looks this year

reviewers.png

567 patches reviewed! Almost 6 times more than one year ago. Those patches come mostly from the 5 contributors I mention in the previous blog post. I’m glad they keep contributing to Nautilus, and doesn’t look like they want to go away.

Some of those contributors gained enough experience to help me with the project as a whole, discussing with other contributors improvements on the code, triaging in Bugzilla and reviewing patches. In this a big thanks goes to Ernestas Kulik, who is doing an amazing job and a great help to me in the parts I most need. And of course my GSOC minions Alex and Razvan who I had an amazing time at GUADEC with 🙂 .

Related to this, I asked on the Nautilus BOF at GUADEC what makes contributing to Nautilus interesting for people, and why they keep doing it. I was surprised to know that all of them agreed that most part of it is not the actual code, but our relationship in the channel and the small community we created inside the Nautilus project. Being responsive to the patches contributed and being present on the IRC channel for questions and random small talk makes the whole experience much more enjoyable. Chatting in the channel while coding to Nautilus became a “one beer with friends” time.

I feel the project is indeed moving in the right direction.

Thanks all!