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
