No more OpenURI when using XDG_CURRENT_DESKTOP=sway and gtk portal #1077

Yes, there is some required configuration now: with x-d-p 1.17.0, maintainers of desktop environments are expected to set up the portals that they want their desktop environment to use. See the portals.conf man page or its source code https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst.

If you're using a complete desktop environment like GNOME or KDE Plasma, it should (eventually) set this up for you. For example, if XDG_CURRENT_DESKTOP is set to gnome, gnome-portals.conf will be used.

If you're piecing together a desktop environment out of individual components, you'll need to provide your own configuration. For example, if XDG_CURRENT_DESKTOP is set to sway, you can create portals.conf or sway-portals.conf in $XDG_CONFIG_HOME/xdg-desktop-portal or /etc/xdg-desktop-portal.

(I don't know which of those models Sway is closest to.)

If no portals.conf is found, there is a fallback which reads the old UseIn fields; but x-d-p-gtk only declares UseIn=gnome. When there is no portal that declares that it should be used for a particular desktop environment, as an intentional change in 1.17.0, x-d-p intentionally does not have the behaviour of older versions that would arbitrarily choose whatever portal happens to be first in alphabetical order and hope that it might work.

Thanks for this clarification. I opened up this corresponding MR on Sway on Alpine Linux:

https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50395/diffs

I'm reopening this because I think we could have a better backwards compatibility story here. -gtk is the closest thing we have to a reference implementation of a portal backend, and it has historically been used (by OS vendors, desktop environments, and users of self-assembled or otherwise unsupported desktop environments) as the portal implementation of last resort. With xdp 1.17.x, that no longer works.

Would it make sense for x-d-p to hard-code -gtk as a last-resort backend (after portals.conf and UseIn), with a warning, before giving up completely?

Or would it perhaps make sense for either x-d-p or x-d-p-gtk, either upstream or in downstream distro packaging, to ship a last-resort /usr/share/xdg-desktop-portal/portals.conf (searched at lowest-precedence, now that #1082 has been merged) that will try gtk for all the portals that it supports in a non-GNOME-specific way?

(I think that means: FileChooser, AppChooser, Print, Notification, Inhibit, Access, Account, Email, DynamicLauncher, Lockdown and Settings; but not Screenshot, Screencast, RemoteDesktop, Background or Wallpaper, which only work on GNOME.)

cc @ebassi @GeorgesStavracas

I'd probably delegate this to downstreams shipping a portals.conf that uses the GTK portal. The state of the GTK portal being an implementation of last resort is not codified anywhere—least of all, in xdg-desktop-portal-gtk itself.

If we want to make x-d-p-gtk a portal of last resort de jure, I'd probably rename it xdg-desktop-portal-fdo, and then drop its optional functionality that depends on mutter/gnome-shell/gnome-desktop.

I'd probably delegate this to downstreams shipping a portals.conf that uses the GTK portal.

Yeah, that's fair.

Thinking about this some more, there are some good reasons to not want to do that, either upstream or in a multi-desktop-environment downstream like Debian:

• that will silence the warnings for other desktop environments, but we want them to see the warnings so they'll start shipping a foo-portals.conf;
• and because it would be higher-precedence than the UseIn fallback, it would do the wrong thing for desktop environments that have their own portal via UseIn but don't yet ship a foo-portals.conf (in Debian that means gnome, phosh, kde, and the wlroots/sway/wayfire/hyprland family, with others existing but currently unpackaged)

So if we want that backwards-compatibility (which I think we temporarily do, to remove barriers to adoption of 1.17 and get the warnings shown to the people who need to see them), it will have to be either in the C code, or a new, lower-precedence-than-UseIn fallback.

It might make more sense for that to be a downstream change rather than something that is done upstream.

If we want to make x-d-p-gtk a portal of last resort de jure, I'd probably rename it xdg-desktop-portal-fdo, and then drop its optional functionality that depends on mutter/gnome-shell/gnome-desktop.

That's an interesting longer-term idea.

I'd prefer to not have any fallback at all, and to make clear that a manual configuration have to be done. It make sure someone actually checked that the implementation works for those environments.

Also, I don't think it make sense for distributions to ship a portals.con with -gtk as fallback. Then I'd prefer the old x-d-p behavior, to fallback to the first available implementation.

In short, current state suits me, even if I had to open this ticket :)

and then drop its optional functionality that depends on mutter/gnome-shell/gnome-desktop.

Happened to have done flatpak/xdg-desktop-portal-gtk#438 without having seen this comment.

I hope it's not inappropriate to leave a small snippet to make sway happy again.

in .config/xdg-desktop-portal/sway-portals.conf

[preferred]
# use xdg-desktop-portal-gtk for every portal interface
default=gtk
# except for the xdg-desktop-portal-wlr supplied interfaces
org.freedesktop.impl.portal.Screencast=wlr
org.freedesktop.impl.portal.Screenshot=wlr

I hope it's not inappropriate to leave a small snippet to make sway happy again.

in .config/xdg-desktop-portal/sway-portals.conf

[preferred]
# use xdg-desktop-portal-gtk for every portal interface
default=gtk
# except for the xdg-desktop-portal-wlr supplied interfaces
org.freedesktop.impl.portal.Screencast=wlr
org.freedesktop.impl.portal.Screenshot=wlr

Can you open a pr to sway to add that? :)

Can you open a pr to sway to add that? :)

as noted in swaywm/sway#4876 (comment) it's user preference for which default portal one might even want, and sway also does not even set XDG_CURRENT_DESKTOP, so the $XDG_CURRENT_DESKTOP-portals.conf name can't even be guaranteed to be correct.

that said, this is a "new" development (that you need a configuration for xdp to work at all), so perhaps now that compositors like sway will not be able to even have portal integration at all without setting XDG_CURRENT_DESKTOP and shipping a matching file, maybe they'd reconsider :)

Can you open a pr to sway to add that? :)

Adding to @nekopsykose's comment, I consider that a downstream issue. So I should really add a PR to fedora (because that's the sway I am using). I am not entirely sure which component though.

@smcv can we consider this issue closed now? It seems like your concerns from #1077 (comment) have been discussed and addressed

#1199 should render this issue solved

I hope it's not inappropriate to leave a small snippet to make sway happy again.

in .config/xdg-desktop-portal/sway-portals.conf

[preferred]
# use xdg-desktop-portal-gtk for every portal interface
default=gtk
# except for the xdg-desktop-portal-wlr supplied interfaces
org.freedesktop.impl.portal.Screencast=wlr
org.freedesktop.impl.portal.Screenshot=wlr

For users wanting to configure custom wlroots-based compositors in this way, note that it should be org.freedesktop.impl.portal.ScreenCast=wlr (i.e., ScreenCast and not Screencast). Without this change, org.freedesktop.impl.portal.ScreenCast is routed to the default backend, and screen casting won't work. That is:

[preferred]
# Use xdg-desktop-portal-gtk for every portal interface...
default=gtk
# ... except for the ScreenCast and Screenshot
org.freedesktop.impl.portal.ScreenCast=wlr
org.freedesktop.impl.portal.Screenshot=wlr

I hope it's not inappropriate to leave a small snippet to make sway happy again.
in .config/xdg-desktop-portal/sway-portals.conf

[preferred]
# use xdg-desktop-portal-gtk for every portal interface
default=gtk
# except for the xdg-desktop-portal-wlr supplied interfaces
org.freedesktop.impl.portal.Screencast=wlr
org.freedesktop.impl.portal.Screenshot=wlr

For users wanting to configure custom wlroots-based compositors in this way, note that it should be org.freedesktop.impl.portal.ScreenCast=wlr (i.e., ScreenCast and not Screencast). Without this change, org.freedesktop.impl.portal.ScreenCast is routed to the default backend, and screen casting won't work. That is:

[preferred]
# Use xdg-desktop-portal-gtk for every portal interface...
default=gtk
# ... except for the ScreenCast and Screenshot
org.freedesktop.impl.portal.ScreenCast=wlr
org.freedesktop.impl.portal.Screenshot=wlr

Just use

default=wlr;gtk. Falls back to gtk if some are not implemented.