Description of problem: I was running F24 Workstation with GNOME as Desktop system and nautilus as file manager. After upgrading to F25 Beta with dnf-plugin-system-upgrade, I missed the desktop icons, and if switching them on by gnome-tweak-tool, I saw that nemo became the factual ile manager instead . Version-Release number of selected component (if applicable): How reproducible: Did not test Steps to Reproduce: 1.Upgrade to F25 Beta Gnome WS 2. 3. Actual results: Now the filemanager is nemo Expected results: nautilus remains filemanager Additional info:
I don't know anything about nautilus and nemo, so I don't even know if the switch is intentional. Could be caused by #1259865 if it is not.
Clearly, we don't want to switch from nautilus to nemo in an upgrade. Carlos, any idea what could be going wrong here ?
There is a possibility Nemo and Nautilus are fighting to control the desktop. Nautilus used to offer the --no-desktop option for that, and Nemo does too. Reading Nemo's code they listen to a different gsetting [0] than Nautilus[1], so it doesn't make sense to me that tweak tool that only modifies the one nautilus listen to [2] has any effect on Nemo at all. Just for checking, is your default file manager still Nautilus? You can try with: $ xdg-open ~ Also, are you using the classic session or regular session? [0] https://github.com/linuxmint/nemo/blob/72715635fa1e5bb76783729f9de36353d800a3ba/libnemo-private/org.nemo.gschema.xml.in#L484 [1] https://git.gnome.org/browse/nautilus/tree/data/nautilus-autostart.desktop.in [2] https://git.gnome.org/browse/gnome-tweak-tool/tree/gtweak/tweaks/tweak_group_desktop.py#n22
(In reply to Carlos Soriano from comment #3) > There is a possibility Nemo and Nautilus are fighting to control the > desktop. Nautilus used to offer the --no-desktop option for that, and Nemo > does too. > Reading Nemo's code they listen to a different gsetting [0] than > Nautilus[1], so it doesn't make sense to me that tweak tool that only > modifies the one nautilus listen to [2] has any effect on Nemo at all. > > Just for checking, is your default file manager still Nautilus? You can try > with: > $ xdg-open ~ Opens a nautilus window (home) > > Also, are you using the classic session or regular session? Gnome on Xorg > > [0] > https://github.com/linuxmint/nemo/blob/ > 72715635fa1e5bb76783729f9de36353d800a3ba/libnemo-private/org.nemo.gschema. > xml.in#L484 > [1] > https://git.gnome.org/browse/nautilus/tree/data/nautilus-autostart.desktop.in > [2] > https://git.gnome.org/browse/gnome-tweak-tool/tree/gtweak/tweaks/ > tweak_group_desktop.py#n22
Additional info: grep -i nautilus $HOME/.local/share/applications/mimeapps.list inode/directory=userapp-firefox-5V1RMV.desktop;gnome-nautilus-folder-handler.desktop;fedora-Thunar-folder-handler.desktop;kde4-gwenview.desktop;kde4-kfmclient_dir.desktop;kde4-dolphin.desktop;userapp-totem-Q2I3EV.desktop;nautilus.desktop; inode/directory=nautilus.desktop
Can you inspect with dconf whether Nemo has activated the desktop option? org.nemo.desktop.show-desktop-icons
If so, can you try to use tweak tool and deactivate the desktop and inspect again the nemo key in dconf to see if that changed at all?
Input: gsettings get org.nemo.desktop show-desktop-icons Output: true Same result without or with activated desktop (by tweak-tool)
aha now it makes sense. Somehow that setting got activated, but neither nautilus or tweak tool have any power on that. I would suggest try to find if Nemo changed that setting somehow in the new version to true by default, or simply it was always true and Nautilus was somehow winning in previous versions in the race to control the desktop, and now is Nemo who does. This is most probably the case since Nautilus in f25 has a separate binary, which probably makes the startup slower. In any case, this is a Nemo bug, if they really consider a bug activate that by default. If not, we most probably have to accept Nemo taking control over the desktop if it's installed, or have a downstream patch for fedora to avoid it with the --no-destop option.
After experimenting a little bit, I could solve my problems with nemo/nautilus parallelism by purging nemo using dnf (erased additionally some cinnamon packages, which I did not use). Now the desktop is fully managed by nautilus.
I have a similar problem after upgrading from F23 to F25: My desktop is now managed by Dolphin (I don't have nemo). For some reason it's running as a daemon: $ ps ax | grep -i dolphin 2910 ? Sl 0:01 /usr/bin/dolphin --daemon If I kill it, all desktop folders are opened by nautilus. I remembered having issues in the past year with a couple of KDE apps that began to start in other DE sessions; one (don't remember which) had inserted itself in MATE's list of autostarting applications and the other was klipper, that started with GNOME. In the first case I just removed it from the list, in the second I had to copy org.kde.klipper.desktop to my .config/autostart/ folder and add X-GNOME-Autostart-enabled=false. None of these worked here. As for other settings, I have: $ gsettings get org.gnome.desktop.background show-desktop-icons true $ xdg-mime query default inode/directory org.gnome.Nautilus.desktop $ xdg-mime query default application/x-gnome-saved-search org.gnome.Nautilus.desktop The only mimeapps.list on my system that references dolphin is (as expected) /usr/share/applications/kde-mimeapps.list. This happens in both Xorg and Wayland sessions and I can't get rid of Dolphin, as I am occasionally sharing this system with a KDE user. Also, I can't find any files referencing dolphin on startup in any of the usual places.
(In reply to Alexander Ploumistos from comment #11) > This happens in both Xorg and Wayland sessions I was wrong, I can only run Xorg not Wayland. Another happy nvidia customer... Dolphin has become quite the Lazarus now, it refuses to stay dead. This is after sending a SIGKILL to dolphin and then trying to open a folder on my desktop: Nov 11 03:26:54 <hostname> dbus-daemon[3407]: [session uid=1000 pid=3407] Activating service name='org.freedesktop.FileManager1' requested by ':1.75' (uid=1000 pid=3838 comm="nautilus-desktop " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") Nov 11 03:26:54 <hostname> dbus-daemon[3407]: [session uid=1000 pid=3407] Successfully activated service 'org.freedesktop.FileManager1' Nov 11 03:26:55 <hostname> dolphin[15918]: Invalid Context= "Apps" line for icon theme: "/usr/share/icons/Mist/22x22/apps/" Nov 11 03:26:55 <hostname> dolphin[15918]: Invalid Context= "Apps" line for icon theme: "/usr/share/icons/Mist/16x16/apps/" Nov 11 03:26:55 <hostname> dolphin[15918]: Invalid Context= "Apps" line for icon theme: "/usr/share/icons/Mist/32x32/apps/" Nov 11 03:26:55 <hostname> dolphin[15918]: Invalid Context= "Apps" line for icon theme: "/usr/share/icons/Mist/48x48/apps/" Nov 11 03:26:55 <hostname> dolphin[15918]: Invalid Context= "Apps" line for icon theme: "/usr/share/icons/Mist/24x24/apps/" Nov 11 03:26:55 <hostname> dolphin[15918]: Invalid Context= "Apps" line for icon theme: "/usr/share/icons/Mist/256x256/apps/" Nov 11 03:26:55 <hostname> dolphin[15918]: Cannot creat accessible child interface for object: PlacesView(0x563fede92810) index: 22 Could this be a dbus issue?
Hey Alexander, comment 12 looks unrelated to me. As per your comment 11, see comment 9, and those are the options we have.
(In reply to Carlos Soriano from comment #13) > Hey Alexander, > > comment 12 looks unrelated to me. As per your comment 11, see comment 9, and > those are the options we have. So I should file a bug against dolphin? Do KDE apps set any gsettings? I can't find anything KDE-related with dconf-editor or gconf-editor.
(In reply to Alexander Ploumistos from comment #14) > (In reply to Carlos Soriano from comment #13) > > Hey Alexander, > > > > comment 12 looks unrelated to me. As per your comment 11, see comment 9, and > > those are the options we have. > > So I should file a bug against dolphin? It's a race to control the desktop, whoever goes faster will win. Not sure you can do something about that or if it's a real bug. Here I was talking about Nemo, I don't know about Dolphin. > Do KDE apps set any gsettings? I can't find anything KDE-related with > dconf-editor or gconf-editor. I don't really know about KDE, I guess some KDE dev could chime in here.
I would like to resolve this without inconveniencing my KDE user, so if you think this should be filed as a separate issue, I don't mind opening another bug. FWIW, I've had 4-5 file managers installed and out of each other's way at any given time since at least F14. In /usr/share/dbus-1/services/ I have 4 file manager services: org.freedesktop.FileManager1.service: [D-BUS Service] Name=org.freedesktop.FileManager1 Exec=/usr/bin/nautilus --gapplication-service org.gnome.Nautilus.service: [D-BUS Service] Name=org.gnome.Nautilus Exec=/usr/bin/nautilus --gapplication-service org.kde.dolphin.FileManager1.service: [D-BUS Service] Name=org.freedesktop.FileManager1 Exec=/usr/bin/dolphin --daemon org.mate.freedesktop.FileManager1.service: [D-BUS Service] Name=org.freedesktop.FileManager1 Exec=/usr/bin/caja --no-default-window Is there a way to disable some of them on a per-user basis?
I don't know more information, afaik this is just unsuported... but I really have no idea, so I will let others answer if there is someone that knows it.
This looks like the ages-old issue of D-Bus activation that it is unable to decide which of multiple implementations of a service to pick. So relying on D-Bus activation in this context is a bad idea.
(In reply to Kevin Kofler from comment #18) > This looks like the ages-old issue of D-Bus activation that it is unable to > decide which of multiple implementations of a service to pick. So relying on > D-Bus activation in this context is a bad idea. Is there at least a workaround for this? I'm willing to bet money that as soon as F25 is released we'll be seeing quite a few duplicates.
(In reply to Kevin Kofler from comment #18) > This looks like the ages-old issue of D-Bus activation that it is unable to > decide which of multiple implementations of a service to pick. So relying on > D-Bus activation in this context is a bad idea. hm? if both listen to the same gsetting, there is no way around this. Nothing to do with dbus...
(In reply to Alexander Ploumistos from comment #19) > (In reply to Kevin Kofler from comment #18) > > This looks like the ages-old issue of D-Bus activation that it is unable to > > decide which of multiple implementations of a service to pick. So relying on > > D-Bus activation in this context is a bad idea. > > Is there at least a workaround for this? I'm willing to bet money that as > soon as F25 is released we'll be seeing quite a few duplicates. Again...the possible options are in comment 9.
(In reply to Carlos Soriano from comment #9) > I would suggest try to find if Nemo changed that setting somehow in the new > version to true by default, or simply it was always true and Nautilus was > somehow winning in previous versions in the race to control the desktop, and > now is Nemo who does. This is most probably the case since Nautilus in f25 > has a separate binary, which probably makes the startup slower. Dolphin does not set a similar setting, or if it does, it is somewhere counter-intuitive and I can't find it. > In any case, this is a Nemo bug, if they really consider a bug activate that > by default. If not, we most probably have to accept Nemo taking control over > the desktop if it's installed, or have a downstream patch for fedora to > avoid it with the --no-destop option. So we consider this a Dolphin bug as well and I should file a bug report? I can already see the flame war starting...
(In reply to Alexander Ploumistos from comment #22) > (In reply to Carlos Soriano from comment #9) > > I would suggest try to find if Nemo changed that setting somehow in the new > > version to true by default, or simply it was always true and Nautilus was > > somehow winning in previous versions in the race to control the desktop, and > > now is Nemo who does. This is most probably the case since Nautilus in f25 > > has a separate binary, which probably makes the startup slower. > > Dolphin does not set a similar setting, or if it does, it is somewhere > counter-intuitive and I can't find it. They need to have some setting for starting and managing the desktop. What it's not clear to me is why that setting, on your setup, is set as true. But that's nothing Nautilus or gnome-tweak-tool can control. > > > In any case, this is a Nemo bug, if they really consider a bug activate that > > by default. If not, we most probably have to accept Nemo taking control over > > the desktop if it's installed, or have a downstream patch for fedora to > > avoid it with the --no-destop option. > > So we consider this a Dolphin bug as well and I should file a bug report? Dealing with Dolphin has probably the same options as Nemo. Which are stated there (so not only a bug for them, as said we can do something downstream. > > I can already see the flame war starting... There is nothing else we can do.
I've opened bug 1394927.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.