Remove desktop support
Note if you are a user, read the blog post with the full explanation, plans and less technical wording.
Abstract
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 in place now 6 years ago, so far has been mostly unmaintained (apart of the rearchitectural work I did two years ago to try to save it somehow). Unfortunately it got to a point where the desktop is blocking us and giving deep issues to further go forward with no direct benefit. Users have expectations for it to work decently and it's not the case.
Problems with the current implementation
- Using GTK+ for compositor bits. Specifically, it uses X server special calls for placing the window in the lowest part of the stack (although it uses a window manager hint called GDK_WINDOW_TYPE_HINT_DESKTOP). It also queries attributes like the workarea to be able to place the window in specific position and size. You can imagine an application trying to act as a window manager is going to be bad, therefore this is discouraged and not supported and can break anytime.
- Not being able to port Nautilus to GTK+ 4. Due to the previous point. If we can port to GTK+ 4 we will have these benefits:
- Using proper labels inside the GtkEntry of search and batch renaming. In GTK+ 3 that's not possible because the architecture for having children widgets in any other widget is not there.
- Better debugging of drawing/GTK+ problems using the inspector.
- We can remove the drawing hacks inside the remnants of eel.
- Not being able to port to new modern views, given that the desktop uses a special case of the canvas view where you can place the icons freely. Something that doesn't make sense for the Nautilus application itself. This makes the code quite tight to the canvas view cases.
- Code of NautilusFile, etc. relies on specific features of the desktop that prevent a more generic approach. Specifically the use of desktop icons to represent files that are not really there (like Home, Volumes, etc). Read NautilusLink for more.
- All the work from Ernestas to rework the backend (fixing issues we had for more than 10 years) is blocked by the desktop. This was actually the last straw for the decision.
- Multimonitor support is less than ideal. Currently the desktop is a big window, with constrains in the canvas view to fit on a common workarea shared by all monitors. This has been a recurrent issue over the years. Making this work better is a difficult and daunting task, given that the canvas view and the desktop of Nautilus assume some things, like being a single window.
- The desktop uses all the Nautilus code, when in reality it only needs a few things. For instance, the desktop window has tabs, window slots for different views (list, canvas), operations UI, search, etc., which we disable on construction, but that they are truly there, making the implementation even more difficult to maintain.
- Several issues with window management appear, given of the desktop being a single window. Specifically, clicking "properties" or "move to" etc. opens a new window in the middle of whatever is the common workarea, and it's not precisely where the attention of the user is at that point.
- The code has accumulated an immense amount of crust over the years, and working on fixing small bugs is always difficult.
- The current integration between desktop and Nautilus app is not ideal, for example, operations are performed in the desktop process, but progress is not shown given that the desktop lacks that UI, which is integrated in the Nautilus toolbar. Also the undo + redo operations are not supported for cross-use between the desktop and the nautilus app.
- Nautilus is not very dynamic code wise. The thing that is impacting most by far is this tie with the desktop.
- It cannot work as a single app entity. For example, for Flatpak.
- We provide this as a optional experience, but we didn't really fix much in the last years since it's not part of the default experience, giving users false expectations. Also, nobody really likes to hack on that code, so nobody shown up to fix the big issues behind.
Solutions
Given the points above, there are three solutions:
- 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 is 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 Nautilus desktop. You can read how to install it later on.
- Make the desktop icons a Shell extension.
Proposal
The best choice is probably to make Nautilus a Shell extension. This will also allow to use JS for better prototyping and Clutter for the good support of layout managers.
Some points we will need to decide upon:
- Nautilus extensions. We can implement the top ones that make sense for the desktop as built-in option, like "open in terminal". This is definitely the most difficult part, since we don't know what extensions could be useful for the desktop, and this will be probably the biggest trade-off of this solution.
- Operations. We will need a D-Bus protocol to communicate to Nautilus for doing operations (so report is done on a Nautilus window too). This is also the case for the current implementation, which is already missing the progress reporting support.
- DND from compositor to GTK+. DND from GTK+ to compositor is supported. We need to decide whether this is something we can live without for a first implementation.
It's possible to check out the extension prototype which is in very early stage.
Alternative solution
As an alternative to the gnome-shell extension, it's also possible to use nemo to handle only the desktop.
Instructions
- Install nemo from your distribution's repositories. On Fedora, enter this command on the Terminal application:
sudo dnf install nemo
- Open a text editor and copy the following text into a new empty file:
[Desktop Entry]
Type=Application
Name=Nemo
Comment=Start Nemo desktop at log in
Exec=nemo-desktop
OnlyShowIn=GNOME;
AutostartCondition=GSettings org.nemo.desktop show-desktop-icons
X-GNOME-AutoRestart=true
NoDisplay=true
- Save the text file as
~/.config/autostart/nemo-autostart-with-gnome.desktop
And that's it! Next time you log in, nemo will automatically display icons over the desktop background. If you don't want to log out, you can also manually start it using the Alt+F2 prompt to run nemo-desktop
Optional step: In case you want Nemo to behave more similarly to nautilus desktop layout, you can enable the setting running this command on the terminal:
gsettings set org.nemo.desktop use-desktop-grid false