https://docs.flatpak.org/en/latest/portal-api-reference.html...
There are still apps using legacy gnome/kde specific APIs, but, from what I understand, in the future Flatpak APIs are becoming the defacto standard
On the one hand this means you can support both X11 and Wayland with a single API from a client perspective, on the other you have to use DBus, which is horrendous to use (especially from statically typed languages).
It also doesn't seem to work on my XFCE/X11 desktop, which shows what fragmentation we have now.
Could you explain this? In my experience DBus provides you with a schema, the exposed DBus interface describes the callable methods, their arguments and types, readable properties, and signals.
Just like with SQL it's useful to create a layer that takes advantage of the statically typed powers of the language.
Usually there are tools that use introspection (or the XML introspection data) to generate "types" (ie. this layer).
Gnome people push for everything Dbus, and many Wayland dev prefer to standardize over Wayland protocol.
It's kinda sad that the APIs are fragmented over two IPC solutions (unlike for eg on Android where everything goes through Binder IPC).
I think the overall the idea is : if it requires permission/sandbox -> Dbus, otherwise Wayland . But in practice there is a lot of disagreements.
Context: https://wayland.emersion.fr/grim/
Here's my key binding config from sway:
bindsym print exec filename=$(date +'screenshot-%Y%m%d-%H%M%S.png') && swaymsg -t get_tree | jq -r '.. | (.nodes? // empty)[] | select(.pid and .visible) | .rect | "\(.x),\(.y) \(.width)x\(.height)"' | slurp | grim -g - /tmp/$filename && notify-send "Screenshot captured" "/tmp/$filename"