[Pkg-utopia-maintainers] Bug#994865: xdg-desktop-portal: Delayed start due to deadlock with Thunar

[Simon McVittie]

Control: retitle -1 xdg-desktop-portal: Delayed start due to deadlock with Thunar

On Thu, 30 Sep 2021 at 08:20:31 +0200, Vincent Bernat wrote:
> Sep 30 07:58:21 chocobo xdg-desktop-portal[1730]: XDP: Failed to create FileManager proxy: Error calling StartServiceByName for org.freedesktop.FileManager1: Timeout was reached

Ugh, the FileManager interface strikes again...

I think file managers being service-activatable for the FileManager
interface is a bad design, to be honest. This means that if you have more
than one file manager installed (for example Thunar + Nautilus, if you
are an XFCE user who shares a machine with a GNOME user), D-Bus activation
for that interface name will give you a randomly chosen file manager, which
I suspect is not what anyone wants.

However, the interface name exists, each desktop's file manager seems to
be service-activatable for that name, and removing that would be a feature
regression; so we're stuck with it.

> I have Thunar installed and I think there may be just a dependency loop

Yes, I think that's it. GTK 3 (specifically GtkApplication) sets up
communication with the Inhibit portal, which it uses as a desktop-neutral
way to watch screensaver status and implement gtk_application_inhibit().
Meanwhile, xdg-desktop-portal sets up communication with the implementation
of FileManager (whatever that might be), to use it to open directories if
requested.

This would be fine, except both of them do this with blocking D-Bus calls,
which makes them deadlock: each is waiting for a reply from the other.

Luckily, this doesn't seem to be critical functionality for
xdg-desktop-portal, so I think we can turn at least the x-d-p side into
an async D-Bus call.

On the GTK side, this is an accident waiting to happen, so ideally GTK
would use async calls for all this too. However, the API of GtkApplication
isn't really set up for that.

    smcv