Description of problem: nemo runs in Gnome sessions and takes over the desktop icons and right-click menu. This was reported and fixed earlier in bug 868496 but it has come back in the latest F19 packages. Version-Release number of selected component (if applicable): nemo-1.8.1-2.fc19.x86_64 How reproducible: every time Steps to Reproduce: 1. install both Gnome and Cinnamon desktops 2. login to Gnome 3. open a terminal and run 'pgrep -lf nemo' Actual results: desktop icons are visible right-click on desktop shows the nemo menu 'pgrep -lf nemo' in a terminal confirms nemo is running Expected results: nemo runs only in Cinnamon Additional info:
Created attachment 748472 [details] screenshot showing nemo running in gnome in a fresh new user account
I don't see any easy solution to this issue as both nautilus and nemo both autostart by default. FYI nautilus does the same in a cinnamon session. Do you have any ideas/solutions for this issue?
The upstream fix [1] mentioned in bug 868496 removed the AutostartCondition line, but I see it's back in Fedora 19: $ cat /etc/xdg/autostart/nemo-autostart.desktop [Desktop Entry] Type=Application Name=Nemo Comment=Start Nemo desktop at log in Exec=nemo -n OnlyShowIn=GNOME;Unity; AutostartCondition=GSettings org.nemo.desktop show-desktop-icons NoDisplay=true [1] https://github.com/linuxmint/nemo/commit/eda34ff3cfdc416ccb4360b8d0166da70b5e5123 Another idea, maybe the OnlyShowIn line should just contain Cinnamon for nemo? OnlyShowIn=Cinnamon;
Oh, never mind, the gsettings path changed: OLD: AutostartCondition=GSettings org.gnome.desktop.background show-desktop-icons NEW: AutostartCondition=GSettings org.nemo.desktop show-desktop-icons And I see my personal settings conflict: $ gsettings get org.gnome.desktop.background show-desktop-icons false $ gsettings get org.nemo.desktop show-desktop-icons true I can fix Gnome by setting org.nemo.desktop show-desktop-icons to false, but then it breaks Cinnamon... Argh...
*** Bug 971454 has been marked as a duplicate of this bug. ***
Imo, one safe approach would indeed adding support for OnlyShowIn/NotShowIn Cinnamon, to cinnamon. Looks like implementing that is at least a little more than trivial though.
cinnamon-1.9.1-5.fc19,nemo-1.8.2-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/cinnamon-1.9.1-5.fc19,nemo-1.8.2-3.fc19
(In reply to Rex Dieter from comment #6) > Imo, one safe approach would indeed adding support for OnlyShowIn/NotShowIn > Cinnamon, to cinnamon. Looks like implementing that is at least a little > more than trivial though. Nemo shouldn't trouble Gnome any more. http://pkgs.fedoraproject.org/cgit/nemo.git/commit/?h=f19&id=49ecc28cba1f0589f14628503ee9b5217bd58678 http://pkgs.fedoraproject.org/cgit/cinnamon.git/commit/?h=f19
I've verified that nemo doesn't autostart in Gnome and nautilus doesn't autostart in Cinnamon. Thanks!
nemo-1.8.2-3.fc19, cinnamon-1.9.1-7.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 974616 has been marked as a duplicate of this bug. ***
For some reason I now am again seeing Nemo in GNOME. I am not seeing Nautilus in Cinnamon but in GNOME Nemo still is taking over the desktop on my machine. cinnamon-1.9.1-13.fc19.x86_64 nemo-1.8.2-3.fc19.x86_64 Just an idea, but what about getting rid of both "Files" .desktop files that start up both file managers, replacing that with a single .desktop file that runs a script that quickly checks whether Cinnamon is running, and then loads Nemo if it is or loads Nautilus if Cinnamon isn't? I'm about to throw something together to see if something like that will work without adding anything to logon time. If it works, I will post it below. If it doesn't, I'll let you know here and perhaps someone can come up with something better as an idea than mine.
Created attachment 762962 [details] Simple script to decide between nautilus or nemo depending on whether cinnamon is running Here is the script file I mentioned throwing together. It is pretty simple but so far it is doing the job for me. If you would like to use it or modify it in any way, go ahead and do so however you might find it useful. You could then create a desktop file that will replace the two current desktop files that will launch the script at logon. The desktop file should probably be placed in /etc/xdg/autostart directory and the original "Files" startup desktop files either switched off in gnome-session-properties, etc., or removed in an updated package that could replace those files with this one. Or, it could just be done programmatically and hard-coded into each DE (a royal pain with all that goes with it in adding more work for maintainers and developers, and opening up potential lines of miscommunication, I know). Hopefully this little script can help and/or spark a better idea.
Created attachment 762964 [details] Proposed Desktop file to place in /etc/xdg/autostart This proposed .desktop file should be placed in /etc/xdg/autostart directory and it assumes that the script file is located in /usr/bin directory. If this is adopted it can be changed and placed however is most useful to the situation.
May or may not be related: https://bugzilla.redhat.com/show_bug.cgi?id=976067
I think there are a few things that need to be rethought about auto-starting applications: 1) Gnome Shell and Cinnamon should be handled as two different desktops. So per application in /etc/xdg/autostart, a decision must be taken on whether it should be started by (overridable) default (as mentioned in comment #6) per desktop type 2) The hard link between Gnome Shell & Nautilus and Cinnamon & Nemo should be removed. I don't see a reason why this should be the case. It might be the default, but every user should be able to decide otherwise. So we need some user settable preferred file manager per user per desktop type I would even go as far as defining multiple per-user desktop session types that can be selected from the display manager where you can select your desktop, window manager and file manager of the day.
The problem with GNOME Shell, as it is in 3.8 (at least in Fedora 19; I have not tested otherwise), is that if the user chooses to use Nemo as the file manager of choice, changing the background does not work. Using Nautilus makes the desktop context menu bring up the correct background changing application. Running Nemo, as it currently is coded, causes the backgrounds application for Cinnamon to run when the user uses the desktop context menu, if also enabling Nemo to handle the desktop. Something in the coding would be needed to select the correct backgrounds control panel application when the file manager of choice handles the desktop and the user uses the context menu to change the desktop background. It would have to be done in both file managers and/or both DEs.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.