Considering Budgie, how about using Dolphin?
Both unity and budgie are for GTK based desktops so dolphin with its large kde and qt based dependencies will not work unfortunately.
Forking that bit of code was mentioned in jbicha link . However trying to find someone to actually do this bit of work and maintain it thereafter is going to be a challenge.
It is not possible to create a new file manager in the month and a half left before the lts freeze date.
Not worried about the LTS, considering Budgie. It would be nice to have Budgie File Manager, rather than Nautilus. The main idea behind Budgie (and Solus) is to create a desktop oriented DE/distro. So, Nautilus with its continuously losing features doesn’t match with Budgie. It would be nice to have a full-featured file manager as Dolphin with Budgie.
Looking at the patches Ubuntu has against upstream Nautilus, the list is still significant in 18.04. You could easily argue that Ubuntu already forks Nautilus and has done for a long time. That said, I am concerned that Ubuntu’s Nautilus doesn’t get as much attention as other components right now. It has 2039 bugs open – an order of magnitude more than other major components like gnome-shell.
Fun fact: Last I checked, nautilus-desktop was an X11 app only (it relies on Xwayland to run at all). So it seems it hasn’t been ported to pure Wayland yet. And even if upstream didn’t kill nautilus-desktop, someone would still need to fix/rewrite parts of it to remove the dependency on X11. Simply forking what exists now is not a solution that will work for very long. Someone would have to commit to fixing the code too.
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.
It’s unclear who and what goals GNOME is currently developing.
Nautilus degrades too fast:
- Extra Pane is missed (Caja has it and it’s great);
- Computer, Devices, Bookmarks, Network zone labels are missed in side-pane;
- directory Parent/Up/Down buttons are missed;
- Reload button is missed;
- nowadays they kill desktop-integration (it’s great that Caja does not do so; user can decide to run it with
On non-Unity and non-GNOME sessions (such as MATE):
- File, Edit, View, Go, Bookmarks, Help menus are missed.
With such GNOME news, I’m more and more convinced that moving Ubuntu to MATE DE by default would be a good idea. It seems that this will never happen.
But MATE applications will work on Unity. It’s great.
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.
How about creating that extension by Ubuntu?
For Budgie, most probably an appropriate action would be done by the Budgie upstream, most probably.
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.
And here we go, we keep Nautilus 3.26 this cycle and will help on the extension once the LTS is mostly around. If you want to see this part of the meeting logs:
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
nautilus-desktophere ends session immediately.
nautiluspackage 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;
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.
nemo-desktop after killing
nautilus-desktop - that should handle the desktop (hopefully!)
You don’t need to remove nautilus.
gsettings set org.gnome.desktop.background show-desktop-icons false
and then try running
nemo-desktop. For some reason it is using a background on mouse hover. Not sure if that’s a theme issue. On the other hand
caja --force-desktop works well.
Future options are:
- Nautilus as file manager and nemo-desktop as desktop
- Nautilus as file manager and caja as desktop.
- Nautilus + Revive nautilus-desktop as nautilus extension (but lacks api to do that,atm)
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.
and so on…
How user-friendly is this GNOME world: “Hello this is GNOME and we pronounce RegEdit as GSettings”!
After some trial-and -errors I have:
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
- on GNOME FlashBack it works after
sudo rm /usr/bin/nautilus-desktop.
Its sad when I see statements like “Budgie being mainly created for Solus”
That really undoes the good work the budgie desktop team (there are many) do to make the desktop agnostic for any distro.
Solus is a consumer of budgie desktop in the same way as ubuntu budgie/manjaro/arch/debian etc.
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.
Please stay on-topic. Take side-discussions to PM or a new thread.
If you didn’t carefully read the entire discussion in the IRC log, then you are behind the curve. The discussion lays out alternatives and a sensible recommended plan for both 18.04 and beyond.