Bug#1050928: enlightenment-data: please provide an enlightenment-portals.conf for xdg-desktop-portal

[Simon McVittie]

On Sat, 16 Sep 2023 at 08:54:11 -0700, Ross Vandegrift wrote:
> That's correct - but I'm afraid this is the only item in this bug report that I
> understand.  I tried to read the documentation you linked, but both assume
> general familiarity with what's going on here.  For me, this all might as well
> be greek.

Sorry, I'm doing my best to strike a balance between "wall of text" and
being clear.

Adapted from an issue report I sent upstream in Xfce,
https://gitlab.xfce.org/xfce/xfce4-session/-/issues/181, which they seem
to have found useful:

xdg-desktop-portal is a D-Bus service providing access to
desktop-environment-related functionality for applications. It was
originally written to provide sandboxed apps (Flatpak, Snap, etc.) with
limited access to resources outside their sandbox with user consent, but
is increasingly also used by non-sandboxed apps (.deb or equivalent), as a
desktop-environment-independent interface to features like screen-sharing
that are otherwise difficult to implement in a cross-desktop way.

Another highly visible use of xdg-desktop-portal is that non-sandboxed
apps are starting to use it as a way to get "native" File -> Open
and File -> Save As... dialogs that blend in nicely with whatever is
conventional in a particular desktop environment, like using GTK when
running GNOME/Xfce/etc., but using Qt in KDE.

x-d-p itself does not contain any desktop-environment-specific code,
and is shared between all desktop environments. However, a lot of what
it does requires use of desktop-environment-specific mechanisms or user
interface conventions. To allow for that, it contacts a desktop-specific
backend (x-d-p-gtk, x-d-p-gnome, x-d-p-kde and so on) and uses that to
provide its full functionality.

The request here is for Enlightenment to nominate one or more of the
available backends as "please use these if available, in this priority
order", so that the maintainer of x-d-p (me) isn't responsible for
guessing what user interface a typical Enlightenment user would usually
want to see (on the basis that I don't use Enlightenment myself, so my
guesses will not be as good as yours).

If none of the available backends are particularly suitable (which I
suspect they're not, unless Enlightenment developers have written one that
I couldn't find), then the one that tends to be used as a user interface
of last resort is xdg-desktop-portal-gtk, which uses GTK user interfaces
for things like file chooser dialogs and permission requests, and just
doesn't implement desktop-environment-specific interfaces like
screencasting and setting wallpaper. The way to set that up would be
this file:

# /usr/share/xdg-desktop-portal/enlightenment-portals.conf
[preferred]
default=gtk;

At the moment, x-d-p is hard-coded to do the equivalent of that as
a fallback when run under a desktop with no specific configuration,
but that's a Debian-specific patch which upstream are unlikely to
accept, so I don't want to keep that forever (I'm discussing options
with them). Providing enlightenment-portals.conf will future-proof
enlightenment against that fallback changing.

If Enlightenment is moving towards Wayland (which it seems is currently
an experimental feature) then its upstream developers will presumably
start providing its own portal backend at some point, to give apps a way
to ask permission for privacy-impacting things (like screen recording)
that are silently allowed for all apps under X11, but not generally
possible under Wayland without going via either something like x-d-p,
or a desktop-environment-specific private interface.

> I don't know of any portal requirements for Enlightenment, but I'm not really
> clear whether or not that's what you're asking for.

This is not about whether Enlightenment itself wants to use portals
(it probably doesn't). Instead, the question is: when non-Enlightenment
apps like Chromium that you run under Enlightenment ask to use a portal,
which backend is used to implement that?

> How would I test a change that implemented what you're requesting?

A way to test this while using only Debian main would be to install:

    libportal-tests-gtk3 xdg-desktop-portal xdg-desktop-portal-gtk

and run, in separate terminals:

    /usr/libexec/xdg-desktop-portal --verbose --replace

    GTK_USE_PORTAL=1 portal-test-gtk3

Normally xdg-desktop-portal is started by D-Bus activation and sends
some limited logging to the systemd Journal, but running it with
--verbose --replace lets you see some more of what it's thinking.

portal-test-gtk3 is a simple GTK app that talks to various portal
interfaces (File -> Open dialog, File -> Save As... dialog, sending a
notification, taking a screenshot, asking to be allowed to run in the
background, and so on) as a stand-in for a real, useful application for
testing purposes.

If it's working correctly, then xdg-desktop-portal shouldn't log any
warnings about missing portals.conf files during startup, and at least
these interfaces should work:

- file chooser dialogs (open/save)
- "Notify me!" (assuming you have a freedesktop.org Notifications
  implementation, which if I understand correctly is built-in in
  Enlightenment)

If you have the necessary supporting infrastructure, these should too:

- the hyperlink to the GNOME website (if you have freedesktop.org
  URL scheme handlers set up so that `gio open http://example.com`
  from libglib2.0-bin also works correctly, because x-d-p-gtk uses the
  same library calls)
- Email -> Compose (if you have a mailto: URL handler)
- Account -> Update (if you have accountsservice installed)

It's expected for some of the interfaces not to work without Enlightenment
providing a desktop-specific backend: Screenshot, Screencast and Wallpaper
definitely won't.

A more realistic test would be to install a sandboxed Flatpak/Snap app and
try to use portal'y things from inside the sandbox.
https://flathub.org/en-GB/apps/xyz.tytanium.DoorKnocker and
https://flathub.org/apps/com.belmoussaoui.ashpd.demo are convenient test
apps that show and exercise lots of portal interfaces.

> And what are the consequences of not doing this?

In the very short term, you'll see some warning spam from
xdg-desktop-portal (normally in the systemd journal, but if you run it
in a terminal with --verbose --replace, it'll appear in that terminal),
and Enlightenment users will get the GTK portal implementation as a
last-resort implementation, which might not be what you or they would
have wanted (or it might be what you/they would want - I don't know, which
is why leaving it for me to decide what you get isn't ideal).

In the medium term, if/when xdg-desktop-portal stops hard-coding x-d-p-gtk
as an arbitrary backend of last resort, apps that want to use portals won't
work correctly under Enlightenment. This is mostly going to affect sandboxed
Flatpak/Snap apps, and also OS-level apps that sandbox part of themselves
for better security (Chromium and any WebKitGTK-based web browser). The
most visible example is that File -> Open... in a sandboxed app won't work.

In the long term, if/when Enlightenment starts providing its own portal
backend (so that apps can get "native"-looking UI dialogs, or take
screenshots under Wayland, or do screencasting/remote-desktop under
Wayland, and so on), an enlightenment-portals.conf will be necessary to
get that backend to be used as expected.

    smcv