> A portal frontend service for Flatpak and possibly other desktop containment frameworks.
When it comes to global shortcuts, I'm not saying it has a super easy solution, but it's something that it's essential to support. Wayland intentionally doesn't, and I can't see that changing in the short term (as you also agree)
xdg-desktop-portal itself originates from Flatpak[3], which makes me think it's more like to related to Canonical/Ubuntu rather than being something RH drove.
[1] https://github.com/emersion/xdg-desktop-portal-wlr https://news.ycombinator.com/item?id=32008412 (2 pts, 30 min ago)
PipeWire is truly a godsend for screen recording on Wayland, not very long ago, if at all, every desktop environment / compositor had their own home brewed protocol and developing anything related to screen recording on Wayland was a massive pain [1]. I still can not fathom how Wayland could even exist this long without any decent way to do screen recording and I also do not get why there is no official protocol or at least extension for this!
But thanks to PipeWire some first projects finally support screen capturing on Wayland. Both Firefox (via webrtc) [2] and OBS [3] directly interface with PipeWire. For my personal project Weylus [4] I opted for the gstreamer plugin as at the time the documentation for PipeWire itself was very lacking and I could not figure out how to get it to work. Fortunately gstreamer is better documented and it turned out to be rather easy to use. But it shows that all this is still in an early stage as I hit quite some bugs, probably the most egregious (maybe even somewhat funny) one is KDE's kwin_wayland crashing if you hover the cursor over any window close button while screen recording [5], sadly it doesn't seem to be fixed yet. For some more bugs I've hit, see [6].
Something I am a little worried about is that flatpak with their xdg-desktop-portal [7] is now responsible for the de facto standard how screen recording is negotiated on Wayland. I fear that this means if flatpak does not need a feature, even if it makes sense in another context, it probably won't ever be implemented. For example something I require for my project are proper window names and their position as well as size, but apparently this is nothing essential for flatpak and the issues I have opened have largely been ignored [8]. This is by no means meant as an accusation, just an observations that things are not all good.
[1]: https://github.com/H-M-H/Weylus/issues/3#issuecomment-652670...
[2]: https://webrtc.googlesource.com/src/+/refs/heads/main/module...
[3]: https://github.com/obsproject/obs-studio/blob/master/plugins...
[4]: https://github.com/H-M-H/Weylus
[5]: https://bugs.kde.org/show_bug.cgi?id=435042
[6]: https://github.com/H-M-H/Weylus/issues/3#issuecomment-808940...
[7]: https://github.com/flatpak/xdg-desktop-portal
[8]: https://github.com/flatpak/xdg-desktop-portal/issues/created...
For wlroots-based compositors like sway here's the most lightweight solution: https://hg.sr.ht/~scoopta/wlrobs
For mutter (GNOME): https://github.com/flatpak/xdg-desktop-portal + pipewire
If your application is inside a sandbox, it communicates with another process that presents the file chooser and hands over permissions based on the user's selection.
It is possible to choose directories in the same way, and portals are always improving: https://github.com/flatpak/xdg-desktop-portal.
Plenty of Flatpak applications actually do use this, but the author of this website loves to pick out the ones that don't so he can act like the project is flawed to the core and justify his sensationalist domain name. But actually it is very solvable, it is being solved, and in many cases you can tighten an application's sandbox with a two line diff.
It does have that through portals:
https://github.com/flatpak/xdg-desktop-portal
If you Flatpak a Gtk+ 3 or modern Qt application you get portals for free. E.g. I packaged a Qt application and I am not sharing the home directory - when the user opens a file it uses the Qt/KDE portal (similarly to macOS, ChromeOS, etc.).
As far as I understand the problem is that portals are only available for Gtk+ and recent Qt versions. Some of the applications that the posts mentions use toolkits that probably don't support portals (Java JDK, wxWidgets, etc.).
The situation for Linux is a bit different than e.g. macOS, where practically everything uses Cocoa and Apple could just throw the switch.
So, for applications that do not use vanilla Gtk+ or Qt they still need to make the home directory visible or they would not be Flatpack'able.