Yes, xdg-desktop-portal is a standard dbus interface. The interface covers file picker, print, screenshot, screencast, etc. The implementation of the interface (the "backend") is expected to be provided by the desktop environment in some way that makes sense for that DE. So gnome has xdp-gnome, kde has xdp-kde, etc, and there are some like xdp-gtk that are DE-agnostic but toolkit-specific.
Backends can implement a subset of the interfaces, and xdp can be configured to try multiple backends in sequence until it finds one that provides the interface that the application wants. Eg xdp-wlr for wlroots-based Wayland compositors only implements compositor-specific interfaces like screencast, so users would chain it with something like xdp-gtk for other interfaces like file picker.
Native applications usually use their toolkits' API for showing file picker dialogs etc, and xdp's file picker interface is primarily used by flatpak applications since that is a way for sandboxed applications to read/write outside their sandbox. But it's not impossible for native applications to also use it, as zed is doing.
Backends can implement a subset of the interfaces, and xdp can be configured to try multiple backends in sequence until it finds one that provides the interface that the application wants. Eg xdp-wlr for wlroots-based Wayland compositors only implements compositor-specific interfaces like screencast, so users would chain it with something like xdp-gtk for other interfaces like file picker.
Native applications usually use their toolkits' API for showing file picker dialogs etc, and xdp's file picker interface is primarily used by flatpak applications since that is a way for sandboxed applications to read/write outside their sandbox. But it's not impossible for native applications to also use it, as zed is doing.
https://flatpak.github.io/xdg-desktop-portal/docs/api-refere...