Bug 1394927

Looks a lot like a consequence of a long-requested dbus feature, bug #484945
"D-Bus activation needs a way to prefer one service over the other depending on the running desktop environment"

Not sure if there's anything we can do about it :(

(In reply to Rex Dieter from comment #1)
> Not sure if there's anything we can do about it :(

Take it up with freedesktop.org?

We did long ago too, see
http://bugs.freedesktop.org/show_bug.cgi?id=20099

Well I wouldn't call this a "corner case" and I'll be damned if I start running containerized DEs or a different VM whenever I want to test something in another DE.
I'll write about this in @devel, but I don't know the technical details or the history of the standard, so when I do, please feel free to chime in.

If you ask *me*, I would argue that one way forward would be this:

If gnome wants to use nautilus specifically, then it should be using
org.gnome.Nautilus
which is provided by only nautilus, not the generic
org.freedesktop.FileManager1
dbus service.

As I explained at length in bug 484945 comment 33, the only way for this to work right now is:

1) nothing should provide a .service file for such an interface;
2) the desktop session must autostart its preferred provider, at least in the background, which will continue to run for the duration of the session.

As far as the file manager is concerned:

* in Cinnamon, the desktop Computer/Home/Trash icons are provided by default and via Nemo (their Nautilus fork), so this generally won't be a problem (IOW nemo will catch the call to this interface).

* in GNOME, the desktop Home/Trash icons are disabled by default, but when enabled (either in Tweak Tool->Desktop->Icons on Desktop [ON], or /org/gnome/desktop/background/show-desktop-icons=true in dconf), they are then provided by Nautilus and therefore this is a workaround.

* in MATE, the desktop Computer/Home/Trash icons are provided by default and via Caja (their Nautilus fork), so this generally won't be a problem.

* in KDE Plasma, the desktop Trash icon is NOT provided via dolphin, so unless dolphin is actually running, this could be a problem.

* in other desktops such as LXDE, LXQt, and XFCE, their file managers (pcmanfm, pcmanfm-qt, and Thunar, respectively) do run in the background by default, but do not yet support this interface, and so the user will either get a foreign file manager, or none at all.

In order for this to work seamlessly without changing how DBus service activation works, the following must occur:

* the .service files must be removed from each of these packages.

* 'dolphin --daemon' should be started with the KDE Plasma session.

* in Cinnamon (nemo), GNOME (nautilus), and MATE (caja), the file manager should always be started in "desktop-background-only" mode by the session (not only if desktop icons are on), and turning desktop icons off should not cause the file manager to exit.

* support for this interface needs to be added to pcmanfm{,-qt} and Thunar.

For the past few hours I've been reading the D-Bus service specification, bug reports in several desktop environments and distros and I think I'm getting more confused by the minute, so please bear with me.

(In reply to Yaakov Selkowitz from comment #6)
> 1) nothing should provide a .service file for such an interface;

Taking as an example the 4 file manager service files I have on this system, do you mean that none of them should have been there in the first place or that using "Name=org.freedesktop.FileManager1" as well as naming the files org.foo.bar.FileManager1.service is wrong and they should be replaced with their individual names?
e.g.:
org.mate.caja.service:
[D-BUS Service]
Name=org.mate.caja
Exec=/usr/bin/caja --no-default-window

If it is the second (which I very much doubt), what should be the "default" in org.freedesktop.FileManager1.service? That file belongs to nautilus.


> 2) the desktop session must autostart its preferred provider, at least in
> the background, which will continue to run for the duration of the session.

Assuming that the service file issue has been taken care of, let's say that on a multi-user system with multiple DEs, a particular user wants to run GNOME and MATE with gentoo (which AFAIK does not provide desktop icons, so it needs nautilus and caja to be running) as their default file manager. The proper way would be to drop a desktop file for gentoo in their .config/autostart/ with "OnlyShowIn=GNOME;MATE;", a couple more for nautilus and caja with "NotShowIn=GNOME;MATE;" and on top of that all add an entry in their mimeapps.list? If not, how could that be accomplished?

At the very least and until whoever fixes whatever need fixing, is there something I can do on this system -even if I have to redo it after a potential update- so that I can have nautilus open my desktop folders when I'm in GNOME and dolphin when I'm using KDE?

Thank you for your patience, I hope you can untangle this mess in my head.

(In reply to Alexander Ploumistos from comment #7)
> (In reply to Yaakov Selkowitz from comment #6)
> > 1) nothing should provide a .service file for such an interface;
> 
> Taking as an example the 4 file manager service files I have on this system,
> do you mean that none of them should have been there in the first place or
> that using "Name=org.freedesktop.FileManager1" as well as naming the files
> org.foo.bar.FileManager1.service is wrong and they should be replaced with
> their individual names?

To fix this mess, I meant the former should be done.

> > 2) the desktop session must autostart its preferred provider, at least in
> > the background, which will continue to run for the duration of the session.
> 
> Assuming that the service file issue has been taken care of, let's say that
> on a multi-user system with multiple DEs, a particular user wants to run
> GNOME and MATE with gentoo (which AFAIK does not provide desktop icons, so
> it needs nautilus and caja to be running) as their default file manager. 
> The proper way would be to drop a desktop file for gentoo in their
> .config/autostart/ with "OnlyShowIn=GNOME;MATE;", a couple more for nautilus
> and caja with "NotShowIn=GNOME;MATE;" and on top of that all add an entry in
> their mimeapps.list?

AFAIK the gentoo file manager does not support the o.fd.FileManager1 interface, so unfortunately this just isn't going to work.

> At the very least and until whoever fixes whatever need fixing, is there
> something I can do on this system -even if I have to redo it after a
> potential update- so that I can have nautilus open my desktop folders when
> I'm in GNOME and dolphin when I'm using KDE?

The easiest short term workarounds at the moment:

In GNOME, turn on desktop icons (Tweak Tool->Desktop->Icons on Desktop [ON]).

In Cinnamon and MATE, desktop icons are already on by default, so as long as that hasn't been changed, nothing more should be required.

In KDE, create a ~/.config/autostart/dolphin.desktop file with the following contents:

[Desktop Entry]
Type=Application
Name=Dolphin
Comment=KDE file manager
Icon=system-file-manager
Exec=dolphin --daemon
OnlyShowIn=KDE;

Created attachment 1220827 [details]
local & system-wide autostart entries and D-Bus services

Thank you for the clarifications.

I had already tried setting dolphin to OnlyShowIn=KDE, but that didn't work. In KDE I get dolphin to manage my files everywhere, but in GNOME it's still dolphin that is opened when dealing with desktop folders. Is it supposed to be run as a daemon at initlevel 5, or only when someone has logged in a KDE session. Btw, I am using gdm.

(In reply to Yaakov Selkowitz from comment #8)
> The easiest short term workarounds at the moment:
> 
> In GNOME, turn on desktop icons (Tweak Tool->Desktop->Icons on Desktop [ON]).

It is set to ON.

> In KDE, create a ~/.config/autostart/dolphin.desktop file with the following
> contents:
> 
> [Desktop Entry]
> Type=Application
> Name=Dolphin
> Comment=KDE file manager
> Icon=system-file-manager
> Exec=dolphin --daemon
> OnlyShowIn=KDE;

I have, but no change.
I am attaching all of my autostart files as well as the D-Bus services, hopefully you might be able to spot something I can't.

(In reply to Alexander Ploumistos from comment #9)
> Created attachment 1220827 [details]
> local & system-wide autostart entries and D-Bus services
> 
> Thank you for the clarifications.
> 
> I had already tried setting dolphin to OnlyShowIn=KDE, but that didn't work.
> In KDE I get dolphin to manage my files everywhere, but in GNOME it's still
> dolphin that is opened when dealing with desktop folders.

You have Icons on Desktop set to ON, and there are Home and Trash icons on your GNOME desktop, yet dolphin still gets started?  I don't see how that's possible.  When *exactly* do you see dolphin in GNOME?

> (In reply to Yaakov Selkowitz from comment #8)
> > In KDE, create a ~/.config/autostart/dolphin.desktop file with the following
> > contents:
[snip]
> 
> I have, but no change.

You mean something other than dolphin is opening in KDE Plasma?  Did you log out and back in after adding that?

(In reply to Yaakov Selkowitz from comment #10) 
> You have Icons on Desktop set to ON, and there are Home and Trash icons on
> your GNOME desktop, yet dolphin still gets started?  I don't see how that's
> possible.  When *exactly* do you see dolphin in GNOME?

When I log in to GNOME, dolphin is already running daemonized. Even if I kill the process and then proceed to double click a folder on my desktop, it is restarted and the folder opens in dolphin. That's when I see the "Activating service name='org.freedesktop.FileManager1'" messages in my journal.

> You mean something other than dolphin is opening in KDE Plasma?  Did you log
> out and back in after adding that?

No, dolphin runs fine in KDE, it is in GNOME that I get dolphin instead of nautilus when I try to open desktop folders. I have even tried rebooting, without any luck.

(In reply to Yaakov Selkowitz from comment #10)
> You have Icons on Desktop set to ON, and there are Home and Trash icons on
> your GNOME desktop, yet dolphin still gets started?  I don't see how that's
> possible.  When *exactly* do you see dolphin in GNOME?

Also, if I kill or quit nautilus, I lose my desktop icons, so it is nautilus that's running, it just won't open any desktop folder.

Opening desktop folders and responding to o.fd.FM1 are two different things.  What is the result of:

grep inode ~/.config/*mimeapps.list

(In reply to Yaakov Selkowitz from comment #13)
> Opening desktop folders and responding to o.fd.FM1 are two different things.

Never mind.  That *used* to be true, but I had been looking at F24 until now.  After trying F25 Beta (with all updates applied), things have definitely changed.

As of F25 (GNOME 3.22), the desktop functionality in nautilus has been split out into a separate nautilus-desktop binary, which calls o.fd.FM1 when an icon has been "opened".  Ultimately, this split, combined with a lack of "daemon" functionality in nautilus proper, makes it impossible for this to work correctly.  IMO nautilus-desktop should be changed to use org.gnome.Nautilus instead.

A temporary workaround is to remove the following files if they exist:

/usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service
/usr/share/dbus-1/services/org.mate.freedesktop.FileManager1.service
/usr/share/dbus-1/services/org.nemo.freedesktop.FileManager1.service

That will *leave* nautilus' own .service files, which is currently needed for GNOME.  KDE should be fine with the aforementioned autostart file, and Cinnamon and MATE should still be fine as long as desktop icons are on.  Other desktops will end up opening nautilus when o.fd.FM1 is called.  (Obviously, this will have to be repeated whenever any of caja, dolphin, or nemo are updated).

Is this worthy of another bug report?

I made a new user earlier, just to make sure I don't have something weird in my home folder and the symptoms were identical.

I'll try your suggestions later tonight and report back.

(In reply to Alexander Ploumistos from comment #15)
> Is this worthy of another bug report?

Eventually, but we'll need a consensus first.

> I made a new user earlier, just to make sure I don't have something weird in
> my home folder and the symptoms were identical.

Yeah, it's not you, just a change in F25.

> I'll try your suggestions later tonight and report back.

BTW, you'll probably have to log out and back in before the changes will help.

I kept org.freedesktop.FileManager1.service and changed the suffix on all the other FileManager1 service files and indeed all DEs seem to work as expected and no dolphins are swimming around in GNOME any more.

I'll post a follow-up on devel, just in case any interested parties are not aware of this yet.

Thanks again!

Another, more permanent, workaround is to create a symlink (~/.local/share/dbus-1/services/org.freedesktop.FileManager1.service) pointing to your favourite file manager under your home dir, e.g. dolphin:
$ mkdir -p ~/.local/share/dbus-1/services/
$ cd ~/.local/share/dbus-1/services/
$ ln -sf /usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service org.freedesktop.FileManager1.service

the same works for Nautilus and Nemo; I never could get caja to work for some reason (when I symlink it, it spews some gsignal errors in the session log). You need to logout -> login after creating/changing the symlink so that the dbus stuff is reinitialised.

I tested with GNOME on F25.

This workaround has caveats, e.g. if you have desktop icons enabled under GNOME and use nemo you'll get two Home icons (the second one being from nemo)...

For the record, AFAIK Firefox uses org.freedesktop.FileManager1 to call a file manager to "Open containing folder" from its Download Manager.

(In reply to Ahmad Samir from comment #18)
> Another, more permanent, workaround is to create a symlink
> (~/.local/share/dbus-1/services/org.freedesktop.FileManager1.service)
> pointing to your favourite file manager under your home dir, e.g. dolphin:
> $ mkdir -p ~/.local/share/dbus-1/services/
> $ cd ~/.local/share/dbus-1/services/
> $ ln -sf /usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service
> org.freedesktop.FileManager1.service

I hadn't seen a reference to a per-user directory for D-Bus services in the specification. Do they take precedence over those in any other location? In that case a user wouldn't need to fiddle with things that require root privileges and risk damaging the system for other users, they could have a local copy of each file with Exec=<file manager of choice>.

On the other hand, if the user wanted to work with multiple DEs, they would have to create a start-up script, e.g. something in .config/autostart/ with X-<DE>-Autostart-enabled=true (or multiple falses?) that would switch the executables in the local D-Bus service files, otherwise they'd end up with weird-looking desktops.
 
> the same works for Nautilus and Nemo; I never could get caja to work for
> some reason (when I symlink it, it spews some gsignal errors in the session
> log). You need to logout -> login after creating/changing the symlink so
> that the dbus stuff is reinitialised.

Have you tried this with a regular file instead of a symlink?

> This workaround has caveats, e.g. if you have desktop icons enabled under
> GNOME and use nemo you'll get two Home icons (the second one being from
> nemo)...

In this particular case (nemo in GNOME), can you enable desktop icons in nemo and disable them in org.gnome.desktop.background.show-desktop-icons?

> For the record, AFAIK Firefox uses org.freedesktop.FileManager1 to call a
> file manager to "Open containing folder" from its Download Manager.

I have a low-spec laptop that started with GNOME, but is now running MATE and I kept wondering how Firefox chooses the file manager. I'll try to accommodate both DEs based on the information you provided as soon as I upgrade it to F25.

(In reply to Alexander Ploumistos from comment #19)
TBH, I don't think I read the spec; some time ago I had to figure out a workaround for the, back then, newly introduced org.freedesktop.FileManager1.service; so I checked `strings /usr/bin/dbus-daemon` and it had XDG_DATA_HOME, then I played it by ear from there on. Mostly a lucky guess.

IIUC, session services in ~/.local/share/dbus-1/services take precedence over those in /usr/share/dbus-1/services. Searching now for that path I got[1] which confirms that conclusion.

A regular file under ~/.local/share/dbus-1/services/ should work too.

> In this particular case (nemo in GNOME), can you enable desktop icons in nemo and > disable them in org.gnome.desktop.background.show-desktop-icons?

I didn't test that...

[1]https://bugs.freedesktop.org/show_bug.cgi?id=50955#c1

marking as FutureFeature (to avoid autoclose)

FEDORA-2019-1f174ad525 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1f174ad525

Latest dolphin builds for f31+ referenced here implement the suggestions from comment #6 (to autostart 'dolphin --daemon' in plasma sessions, and remove the dbus activation file)

baloo-widgets-19.08.2-1.fc31, dolphin-19.08.2-2.fc31, dolphin-plugins-19.08.2-1.fc31, kate-19.08.2-1.fc31, kdialog-19.08.2-1.fc31, keditbookmarks-19.08.2-1.fc31, kfind-19.08.2-1.fc31, khelpcenter-19.08.2-1.fc31, konqueror-19.08.2-1.fc31, konsole5-19.08.2-1.fc31, yakuake-19.08.2-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1f174ad525

baloo-widgets-19.08.2-1.fc31, dolphin-19.08.2-2.fc31, dolphin-plugins-19.08.2-1.fc31, kate-19.08.2-1.fc31, kdialog-19.08.2-1.fc31, keditbookmarks-19.08.2-1.fc31, kfind-19.08.2-1.fc31, khelpcenter-19.08.2-1.fc31, konqueror-19.08.2-1.fc31, konsole5-19.08.2-1.fc31, yakuake-19.08.2-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.