On Tue, 25 Apr 2017 at 18:37:43 +0200, Michael Biebl wrote: > Am 25.04.2017 um 18:21 schrieb Jason Crain: > > I don't know if there's a way to tell dbus to start different > > services for different DEs.
There is not. The only package that makes the D-Bus name foo.bar.baz activatable, if any, should be the one that contains /usr/share/dbus-1/services/foo.bar.baz.desktop. Nautilus actually sort of gets this right - it provides /usr/share/dbus-1/services/org.freedesktop.FileManager1.service - but that can't work if other file managers want to be co-installable with Nautilus. In Ben's file listing, both XFCE and MATE install a file of the wrong name for this service. Recent Lintian will advise maintainers not to do this: https://lintian.debian.org/tags/dbus-session-service-wrong-name.html It would be better if all the file managers followed rules like these: * none of them install a .service file with Name=org.freedesktop.FileManager1 (so sending messages to that name never starts a file manager, only communicates with an existing file manager) * none of them fail to start up if a different file manager already owns the org.freedesktop.FileManager1 name (they can either replace it, if it will let them, or quietly stay out of its way) * they can be service-activatable if they want to, but only via their implementation-specific names like org.gnome.Nautilus Nautilus gets very close to this - it uses org.gnome.Nautilus for its GApplication, and treats inability to acquire the org.freedesktop.FileManager1 name as non-fatal. However, it does install a D-Bus session .service file for it, which I think is not a good idea. I think the actual root cause of this bug is that nautilus-desktop/nautilus-desktop-application.c (the part of Nautilus that draws files on the desktop) uses org.freedesktop.FileManager1 to communicate with Nautilus. This means that if you double-click on a folder on the desktop while Nautilus and some other file manager are installed, but neither is currently running, service-activation will pick a random file manager to run. This is clearly not very helpful. I speculate that in Ben's case, dbus-daemon might be selecting a file manager that is broken in some way, such that it silently fails to start up. Running "dbus-monitor --session" while reproducing this bug might provide evidence for or against this. I think it would be better for nautilus-desktop-application to use the org.gnome.Nautilus bus name, so it always launches specifically Nautilus. The down side of this is that if for some reason you are using Nautilus to display folders on your desktop, but you are also actively running some other desktop's file manager for some reason (let's say Caja), and you double-click on the Foo folder on your desktop, arguably you might prefer it if ~/Desktop/Foo was opened in Caja rather than Nautilus. But that seems rather a contrived setup... > Having multiple D-Bus service files provide the same D-Bus name and > relying on D-Bus activation sounds like a recipe for disaster as you > will get unpredictable behavior depending on what's installed. Yes. Don't do this. dbus-daemon has no concept of priority for files in the same directory: if you try to autostart org.freedesktop.FileManager1 while multiple .service files with that Name exist in the same directory (and none in a higher-priority directory like ~/.local/share), you will get a randomly chosen implementation dependent on readdir() order. > I wonder if it wouldn't be better if desktop environments started an > implementation of their choice via an XDG autostart file which is > specific to their desktop environment via OnlyShowIn= Yes, probably. I'd also be happy to review designs and patches from any desktop environment maintainers who want to define a way for this to work, perhaps something like this: # /usr/share/dbus-1/services/org.gnome.Nautilus.service [D-BUS Service] Name=org.gnome.Nautilus Exec=/usr/bin/nautilus --gapplication-service [Implements org.freedesktop.FileManager1.service] ConditionDesktop=GNOME;Unity; However, I'm unlikely to get round to writing a formal specification for that, or implementing it. S