Files (Nautilus) v3.28 will lose the desktop icons capability

A commit has been accepted into GNOME to remove the desktop icons capability from Files.

Reasoning is that it removes lots of deprecated code and prevents future enhancements to Files (Nautilus).

There is a prototype gnome-shell extension that has been mooted - no idea if its going to be ready within the 18.04 LTS timescales.

Unfortunately for desktop environments such as Budgie Desktop that depends on key components like Files, we’ll lose the ability to have desktop icons - something Budgie users on the whole want.

Discussion - for the wider GNOME-Shell and Unity user communities what do you think? Is it better to request the Ubuntu Desktop Team to consider sticking with Files v3.26 that has desktop icons or keep with upstream GNOME and push for Files v3.28 that hasnt got this capability?

6 Likes
2 Likes

What does upstream thinking about this? Would upstream fork Nautilus or move to Qt?

Unity really requires nautilus-desktop. The desktop functionality was already decopled from main app. May be that could be packaged as a nautilus extension which is better than shell extension because other non gnome desktop shells can then simply install it by sudo apt-get install nautilus-desktop.

If that’s not possible I would like to stay with Nautilus 3.26 for LTS cycle.

The other option is using Nemo or Caja which we have to distro patch to make it work with Unity.

2 Likes

I’ve played with Nemo briefly under budgie. It does work functionally - it really is an ugly interface with a questionable looking sidebar and the icon-view spacing is huge and quite unusable for medium to large folder contents.

Caja unfortunately brings in a sizeable number of mate components - including mate-desktop itself.

1 Like

Forking code means that someone new will need to maintain it. Given the GNOME reasons why they have dropped this bit of functionality is that they dont have maintainers who like hacking in this area, I can’t foresee someone maintaining another nautilus fork.

The move to Qt is for the desktop GUI - applications such as Files are unaffected by this move.

1 Like

In Budgie settings, you can either enable or disable desktop icons as for now. If Budgie users want that feature, upstream would maintain that, won’t they at Solus-project?

No - all that setting does is toggle the Nautilus setting to turn on/off desktop icons. Budgie Desktop like Unity Desktop depends on Nautilus capabilities to display desktop icons.

Maybe not, https://budgie-desktop.org/2017/01/25/kicking-off-budgie-11/

that is referring to v11 of budgie-desktop which is not available for 18.04 LTS - it is in a very early research and development phase. Here this discussion is referring to current versions of gnome-shell/unity and budgie.

If upstream is not going to move (yet) to Nautilus v3.28, we should also stay with v3.26. If upstream moves on to v3.28, then a patch would be there to enable/disable desktop icons, I believe.

Get rid of the desktop icons. It’s a place where all I get is a bunch of trash. It’s a chance: Maybe I’ll get neater without a desktop. Not without reason there are category folders.

3 Likes

Agreed.

IMHO with the Gnome DE, having desktop icons is redundant. I used to use it prior to installing Ubuntu’s Dock, [which is fantastic BTW] on Ubuntu’s Vanilla Gnome.

If one is using a conventional old school desktop, then sure I could see that feature as being needed. But there are other file manglers :wink: that can do the job.

1 Like

I remember during the 1.0 WWW Bubble, that some ex-Apple engineers got an exorbitant sum from VCs, to develop an improved file manager for Linux. The result was Nautilus.

At the time, there weren’t many good ones, other than MC. If I remember correctly, they ran out of funds before they considered it a completed product. Sh*t maybe I should have researched this before posting, rather than relying on memory. Ah well, I’ll do that now.

1 Like

As a user I want Ubuntu to track upstream Gnome as much as possible. Nautilus is a very active project currently, gets refinements every release and I don’t want to miss out on those.

The architectural changes that will land for 3.28 will have significant UX improvements, such as the GUI not locking up when a file operation takes long or when you connect to a non-existent server. Speed of development will only improve according to the devs, so we’ll be missing out on a lot if we remain on 3.26.

I don’t mind losing desktop icons, but I don’t mind having them either.

9 Likes

I think an extension would be the most efficient for everyone because a fork would make it more aware of the changes made in the original and adjust it in the fork eating time and energy, and use Nemo would be outdated with the graphical interface (Gnome Shell ) it would not look good

1 Like

When the Nautilus developers suggested using Nemo, they didn’t mean to use it instead of Nautilus as the default file manager. They only meant that you could run the nemo-desktop app automatically at login only for the desktop handling feature. For everything else, you can still use Nautilus.

7 Likes

Would packaging two versions of nautilus be an option? Nautilus and nautilus-legacy? The latter staying on 3.26 for Unity and Budgie?

Or creating your own file manager for Budgie…

Would forking the “nautilus-desktop” part of nautilus (from an older commit) and maintain it as a community thing would be a solution ?

I’m trying to look a bit at Nautilus’s code structure to see if it’s possible, but the two code seems to be still a lot interlinked… At first, maybe just forking+renaming and compiling only the “nautilus-desktop” binaries could be a solution, but the “application-only” part would have later to go ?

(I don’t use the desktop icons myself, but I think that it could be a good solution for Unity, Budgie and GNOME Flashback).