Hello all,

We have been discussing our plans with the desktop part of Nautilus for quite a bit of time and in this blog post I’ll explain them.

Context

Nautilus had have a feature called “the desktop” which adds icons on the background of the user workspace, similar to Windows.

The desktop was disabled for the default experience when GNOME 3 came out now 6 years ago, and so far has been mostly unmaintained. I spent around 3 months of work two years ago to try to save it somehow and did a rearchitectural work to try to separate the desktop from the Nautilus app so it won’t affect Nautilus development, and while it achieved some degree of separation, it didn’t achieve its main purpose and unfortunately brought even more problems than we had before. Now it has got to a point where the desktop is blocking us deeply in basically every major front we have set for future releases.

Also we notice that users rightfully have expectations for the desktop to work decently, and we acknowledge this is far from the reality and we are aware that the desktop is in a very poor state.

If you are interested in more technical details of the issues with the desktop implementation you can read them here.

With these points at hand that have accumulated over the years, we are at the point that we need to remove the desktop code inside Nautilus for Nautilus 3.28 to move forward with Nautilus development. You can check the branch with the removal work here, if you look you will see that the desktop is composed by more than 10.000 lines of code given the complexity to create it with the technologies that were available in 1999 (yes, the code is that old :)).

Solutions

With removing the desktop code from Nautilus we have considered these three options, keeping in mind that the ability to have icons on the desktop can be provided by other projects than Nautilus:

Fork Nautilus desktop, one project being the desktop and the other being Nautilus app. This however doesn’t fix anything at all, the issues will still be there and I’ll be very sad for anyone that has to maintain it. Use Nemo desktop. This is, as of today, a more featureful desktop than the one in Nautilus, so probably it’s the best short term solution. It however has similar problems than the ones Nautilus desktop faced. You can read how to install it here. Make the desktop icons a Shell extension.

Proposal

The best option to of those three to move forward is to integrate it in a GNOME Shell extension. Doing what nautilus desktop was doing in an app (Nautilus) while trying to be part of the compositor (GNOME Shell) was a big mistake, and it’s one of the major issues. It’s important if you understand some technical terms to check the issues we were facing to understand how we agreed to this proposal to be the best option. This is true even more nowadays with various technologies being more in the isolation, privacy and secure side (Wayland, sandboxing, etc).

A nice thing of doing a GNOME Shell extension is that it opens the path to a more dynamic desktop workflow, and the good news is that the prototype that we have in place already has fixed one of the oldest bugs we had in the Nautilus desktop, proper multimonitor support!

You can check the extension prototype here (very early prototype). While this extension is the way forward, the time I can spend on it is limited since upstream wise the desktop pattern didn’t make much sense for long time now. So I encourage anyone that knows JavaScript or wants to learn JavaScript and likes the desktop workflow to make it happen, I’ll be there for helping any contributor making code alongside and to expand on new ideas for the desktop workflow that those that like it have in mind. You can check few points that would be nice to have for a first release here. Ping me on IRC if you are interested on it.

Who will experience a change

For those using distributions with desktop pattern workflows (e.g. Ubuntu), I don’t expect anyone to be affected, if those distributions/projects derived from upstream design decisions based on their own design decisions, I expect they will hold into those patterns and provide a desktop workflow in one form or another.

If your distribution didn’t ship a desktop by default and you were using Nautilus desktop, you can check out the options proposed before to continue using a similar workflow.

Fruits of the removal

The question is, when are the fruits of the removal of the desktop going to be noticeable?

Thanks to the removal of the desktop code we are now free to move forward with the complete rework of the Nautilus backend for 3.28, probably the biggest rework ever done in Nautilus. This will allow heavy searches to not make the UI get stuck and to be resource balanced so you could do multiple searches at the same time, it will also provide proper thread handling, ability to pause operations, ability for performance stats (and finally being able to do performance improvements), easy tweak for operations resource balancing, and more.

Another major work that thanks to the removal of the desktop code we can move forward with is the new views that I talked about in a previous blog post. We won’t make it for Nautilus 3.28 since it requires gtk+ work too, but now we can continue improving it in the Nautilus side and hopefully for 3.30 we can finally move to the next generation of content views.

And finally, this also allows for Nautilus to be ported to gtk4. This is really good news in various fronts for Nautilus; hopefully gtk4 stabilizes a little bit more and we can port to it for Nautilus 3.30.

I want to thank Ernestas and Antonio to work on these big changes and the help overall with Nautilus!