Bug#860796: appears to be linked to the lack of a running "nautilus --gapplication-service"

Simon McVittie smcv at debian.org
Tue Apr 25 17:50:13 UTC 2017

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

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:

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

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]
    Exec=/usr/bin/nautilus --gapplication-service

    [Implements org.freedesktop.FileManager1.service]

However, I'm unlikely to get round to writing a formal specification for
that, or implementing it.


More information about the pkg-gnome-maintainers mailing list