-
-
Notifications
You must be signed in to change notification settings - Fork 189
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
Comments
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 If you're piecing together a desktop environment out of individual components, you'll need to provide your own configuration. For example, if (I don't know which of those models Sway is closest to.) If no |
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 |
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.
I'm reopening this because I think we could have a better backwards compatibility story here. Would it make sense for x-d-p to hard-code 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 (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.) |
I'd probably delegate this to downstreams shipping a If we want to make x-d-p-gtk a portal of last resort de jure, I'd probably rename it |
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:
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.
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 :) |
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
|
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 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 :) |
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. |
@ibotty check what i SR-ed to openSUSE https://build.opensuse.org/package/show/X11:Wayland/sway |
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
@smcv can we consider this issue closed now? It seems like your concerns from #1077 (comment) have been discussed and addressed |
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)
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>
#1199 should render this issue solved |
For users wanting to configure custom wlroots-based compositors in this way, note that it should be
|
Just use
|
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 addsway
in theUseIn
, then it works.The 1.17.0 release note mention some change in how implementations are loaded, is there some required configuration now?
The text was updated successfully, but these errors were encountered: