Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
stacyharper opened this issue Aug 22, 2023 · 17 comments
Closed

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

stacyharper opened this issue Aug 22, 2023 · 17 comments
Labels
config Issues with the portal configuration mechanism

Comments

@stacyharper
Copy link

When using Sway, and having -gtk and -wlr installed:

With this last 1.17.0, there is no more available implementation to handle OpenURI requests.

If I edit /usr/share/xdg-desktop-portal/portals/gtk.portal, and add sway in the UseIn, then it works.

The 1.17.0 release note mention some change in how implementations are loaded, is there some required configuration now?

@smcv
Copy link
Collaborator

smcv commented Aug 22, 2023

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.

@stacyharper
Copy link
Author

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

algitbot pushed a commit to alpinelinux/aports that referenced this issue Aug 23, 2023
flatpak/xdg-desktop-portal#1077 (comment)

As explained here, the xdg-desktop-portals loading behavior changed with
this 1.17.0. It will no longer fallback to any matching implementation,
if no one match the $XDG_CURRENT_DESKTOP value.

This add gtk as default implementation, after wlr.

I used -portalsconf as subpackage to match the phosh recipe.
@smcv smcv reopened this Aug 24, 2023
@smcv
Copy link
Collaborator

smcv commented Aug 24, 2023

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.)

@smcv
Copy link
Collaborator

smcv commented Aug 24, 2023

cc @ebassi @GeorgesStavracas

@ebassi
Copy link
Collaborator

ebassi commented Aug 24, 2023

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.

@smcv
Copy link
Collaborator

smcv commented Aug 24, 2023

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.

@stacyharper
Copy link
Author

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 :)

@jadahl
Copy link
Collaborator

jadahl commented Aug 26, 2023

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.

@ibotty
Copy link

ibotty commented Sep 12, 2023

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

@uncomfyhalomacro
Copy link

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? :)

@nekopsykose
Copy link

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 :)

@ibotty
Copy link

ibotty commented Sep 25, 2023

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.

@uncomfyhalomacro
Copy link

@ibotty check what i SR-ed to openSUSE https://build.opensuse.org/package/show/X11:Wayland/sway

bmwiedemann pushed a commit to bmwiedemann/openSUSE that referenced this issue Sep 25, 2023
https://build.opensuse.org/request/show/1113341
by user uncomfyhalomacro + anag+factory
- XDP 0.18.0 requires desktop and other environments to have their own portals.conf
  by adding river-portals.conf, we will avoid some of the problems for portals for
  * File picker -> We default to xdp-gtk since xdp-wlr does not have it.
  * For screenshots/screenshare, we use the wlr supplied interfaces
  For more information, see flatpak/xdg-desktop-portal#1077
  and the release statement for 0.18.0
  This is a workaround for boo#1215641
@GeorgesStavracas GeorgesStavracas added the config Issues with the portal configuration mechanism label Oct 6, 2023
@GeorgesStavracas
Copy link
Member

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

StayPirate added a commit to StayPirate/dotfiles that referenced this issue Oct 10, 2023
Details about this problem can be found here [0]. The quik solution
I cherry picked is here [1].

[0] flatpak/xdg-desktop-portal#1077
[1] flatpak/xdg-desktop-portal#1077 (comment)
gentoo-bot pushed a commit to gentoo/gentoo that referenced this issue Oct 14, 2023
Install a default to avoid breakage: >=1.18.0 assumes that DEs/WMs
will install their own, but we want some fallback in case they don't
(so will probably keep this forever). DEs need time to catch up even
if they will eventually provide one anyway. See bug #915356.

TODO: Add some docs on wiki for users to add their own preference
for minimalist WMs etc.

Thanks to abby from Void for pointing me to void-linux/void-packages@b4c404a
and psykose as well.

Bug: flatpak/xdg-desktop-portal#1017
Bug: flatpak/xdg-desktop-portal#1077
Bug: flatpak/xdg-desktop-portal#1102
Closes: https://bugs.gentoo.org/915356
Signed-off-by: Sam James <sam@gentoo.org>
@GeorgesStavracas
Copy link
Member

#1199 should render this issue solved

@deurzen
Copy link

deurzen commented Mar 22, 2024

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

@uncomfyhalomacro
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
config Issues with the portal configuration mechanism
Projects
Status: Triaged
Development

No branches or pull requests

9 participants