Yep, the dependency of nautilus-desktop is probably the driving force for upstream to move this functionality to a separate gnome-shell plugin now. Otherwise they would have to port it to wayland. Thus work has be done with it either way.
And memory-wise a gnome-shell extension is probably lighter on resources than keeping (whole of) nautilus always active in the RAM.
We are going to discuss this topic today in the ubuntu desktop meeting.
I personnally think we want to have that feature in our ubuntu desktop, at least for the LTS, restricted to the ubuntu session for GNOME Shell (then, the Unity community people can as well use it).
I don’t think we will add another file manager, in parallel to Nautilus, to our maintained code set:
as we told, we want to stay as closed to GNOME as possible, making only the changes we feel useful for our user base (meaning: don’t use a non GNOME app when there is a GNOME app for it)
another file manager will mean some interactions not working or being fully integrated: copy/paste, progress bars, different behaviors.
forking code and maintaining our own isn’t a long term solution.
I personally think our option for the LTS is between:
keeping nautilus 3.26, while working on the Shell extension (but without shipping it this cycle)
upgrading nautilus to 3.28, but it means shipping an extension that realistically won’t be ready in time (due to late notice and other polish we are working on). It thus means less bugs fixed elsewhere in the stack, less integration polish and so on and so on.
Considering how close we are from Feature Freeze to have a reasonable working extension (which will require a good Nautilus API backend service, which isn’t planned for 3.28), I would tend to tell that we maybe should stick with 3.26.
Anyway, this is my own opinion and we’ll discuss it today on IRC, during our weekly desktop meeting.
That is the key issue @chanath - the necessary changes in nautilus 3.28 will not be available to make the gnome-shell extension a truly viable solution.
Also - trying to implement something like desktop icons + implementing nautilus changes that GNOME themselves hasnt yet signed off on in the few short weeks left before feature freeze is an unlikely proposition.
So as @didrocks said - maintaining a “nemo” like solution is not viable for a LTS so you are back to really a binary choice - nautilus 3.28 + no desktop icons or nautilus 3.26 + desktop icons.
Kicking the preverbial “can down the road” … maybe ubuntu 18.10 with “nautilus 3.30” or “nautilus 4” + extension is better.
Anyway - the ubuntu desktop meeting will be making the final decision - we all wait with interest on the outcome.
just installed Nemo on 18.04 LTS VM - it looks great as old pretty Nautilus 3.4 (the last normal and adequate version I think). But after killall nautilus-desktop && nemo & Nemo does not handle desktop. And Caja too.
And it is interesting how current Nautilus behavior would work on gnome-panel (GNOME Flashback session aka gnome-session-flashback) session?
Killing nautilus-desktop here ends session immediately.
Purging nautilus package is not an option - it trying to remove four packages - gnome-session-flashback nautilus nautilus-share ubuntu-desktop.
I removed it manually with sudo rm /usr/bin/nautilus-desktop. The result: I can’t make right click on desktop; nemo & and caja & do not show icons on desktop.
Fixed by sudo apt-get install --reinstall nautilus.
By the way GNOME Flashback session looks good. Please do not remove it from final release. It would be last resort for traditional users.
On 16.04 LTS user can decide which file-manager will maintain desktop (tested for example - Caja or Nautilus).
All of us are invited to a new bright rainbow future without the possibility of selecting the file manager. GNOME developers are very generous.
Considering Budgie DE, the decision whether or not using Nautilus 3.26 or 3.28 would be taken upstream, don’t you think? Budgie being mainly created for Solus, whatever that’s good for Solus would be implemented for Budgie, even if Gnome devs would push for Nautilus 3.28 or even 4.00, don’t you think so?
At this moment in time, the core remaining reason for Budgie even “working” on the GNOME stack, is that it expends an awful lot of effort pretending to be GNOME Shell. To give an architectural insight, consider this small example. To display device & volume notifications, the GNOME Settings Daemon sends a message to the org.gnome.Shell name on D-BUS. In our case this has to be budgie-wm, which has to pretend to be org.gnome.Shell for keyboard layouts and shortcuts to work with GNOME Settings Daemon… Unfortunately, you cannot provide normal GTK+ widgets within the Mutter process (budgie-wm), so then we forward this notification onto the GTK+ process, budgie-daemon.
How user-friendly is this GNOME world: “Hello this is GNOME and we pronounce RegEdit as GSettings”!
After some trial-and -errors I have:
Nemo: after gsettings set org.gnome.desktop.background show-desktop-icons false it:
works on Ubuntu (“Unity”) session;
works with gsettings set org.nemo.desktop ignored-desktop-handlers "['nautilus','nautilus-desktop','nemo','nemo-desktop']" and sudo rm /usr/bin/nautilus-desktop, but does not show background on GNOME FlashBack - reported bug 1742193.
on Ubuntu (“Unity”) session Caja works with caja --force-desktop ;
on GNOME FlashBack it works after sudo rm /usr/bin/nautilus-desktop.
There is nothing to be sad about this, David.
Budgie is desktop agnostic, all right, but Budgie is the flagship desktop of Solus. If you click on https://budgie-desktop.org/home/ and click on “Get”, you’d see that.
And, Solus started because of not-want-to-use-deb-packages idea. (I’ve been with Evolve OS and before. Those forums are not there to see those thoughts.) One day, it’d move to Qt and the file manager would be what it would be, that is, good for Solus and Budgie, with the emphasis on Solus.
I am commenting on Nautilus and Budgie, because, it was what you were worried about; the desktop icons and so on. (I have both, Ubuntu-Budgie 18.04 and Solus 3, both fully updated. Writing from yours, while checking on Solus 3 on the other laptop.) I am actually not worried about desktop icons that much, but sometimes I like doing some work on the desktop, and if there are no desktop icons, I can’t do that.
The reasons presented a good and valid i think. However, removing the functionality before a replacement is ready is very gnomey decision that I consider harmful. The Desktop metaphor works since decades and many users rely on it in the every day work and organizing their work. I use it as a sort of ToDo list, for example to quickly paste some pictures from my camera before properly sorting them… similar to how I use my real desk.
I hope Ubuntu Bionic Beaver will have a replacement ready before removing the functionality.
Edit: Sorry, I missed this reply:
Maybe once we do update to latest nautilus and start using the extension for desktop icons, we can get away from having desktop icon increase in size when we make folders and files larger in nautilus. Good write up @didrocks. Thanks.
First, awesome write ups, solid decision. I’ve got a little bit of a different question I think.
I’ve been a gnome shell user for a long time and prefer that experience but with the merging of Ubuntu Gnome into Ubuntu I’ve know that’s secondary to Canonical’s direction. Again not faulting, your making the right decision for your product.
Getting to the point, I’m not sure what features nautilus 3.28 might have but will there be a way to get a clean latest gnome experience or will we just need to wait till fall?
If I understand you correctly - I think you’re looking for the ‘vanilla-gnome-session’.
I to have been using gnome-shell for some time, (since it’s second iteration). Didn’t like it at first, (actually hated is the better word) but after a month of daily use, I found that I couldn’t go back to a conventional desktop. So I really do appreciate the Gnome-Devs and their HIGs. They do know what they’re doing and it seems they backup at least some of their design decisions by analysing user data. But … I’m digressing.