Make desktop independent of Nautilus

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. Of course this is discouraged for an application, since an application shouldn't be able to do the window manager work.
• Not being able to port Nautilus to gtk4. Due to the previous point. If we can port to gtk4 we will have these benefits:

  • Using proper labels inside the GtkEntry of search and batch renaming. In gtk3 that's not possible because the arquitecture for having children widgets in any other widget is not there.

  • Better debug for drawing/gtk problems using the inspector
  • We can remove the drawing hacks inside the eel "library"
• 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 two solutions:

1. Fork Nautilus, one project being the desktop and the other being Nautilus app. This however, doesn't fix all the points raised above where gtk+ is used for the compositor side of things. Integration would still need to be done and the experience for the desktop itself would be still deceiving.
2. 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, for the duality of grid alignment and free alignment.

Some points we will need to take a decision on:

• 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 DBUS 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 and the Nautilus branch wip/desktop-dbus for the dbus implementation of the basic operations.