Make desktop independent of Nautilus

Since its inception, Nautilus had a feature called "Desktop" which adds icons on the desktop. However, the implementation of it and the use of Nautilus for that purpose seems to bring more problems to Nautilus itself than solutions, even more now that Desktop is not enabled by default. On the other hand, the desktop is important for some distributions, and therefore it needs to exists in some way or another.

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.
  • 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.

  • 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 dynamic. Given the long history of Nautilus, is hard to make changes, and that makes it difficult for future relevance. The single thing that is making it less dynamic is this tie with the desktop.

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.
  2. Make the desktop icons a Shell extension.

Proposal

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.
  • Two layout managers. One being a grid ordered by name, and the other free placement. This is a slight difference, since currently you can have a grid alignment and still not being ordered by name, but this complicates the implementation, would be good to put the scope only to grid + name ordering or free layout. Then the user can eventually order once by using this, and then put it on free layout again.
  • 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.

Experimental extension prototype will live in https://gitlab.com/csoriano/org.gnome.csoriano.desktopicons, and with Nautilus branch wip/desktop-dbus for the dbus implementation of the basic operations.

Apps/Nautilus/Desktop (last edited 2017-06-07 11:14:31 by CarlosSoriano)