[antimba]

> That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care.

For GTK apps, they don’t need to do anything different, as GtkFileChooserNative[1] is recommended for non-sandboxed apps as well. GtkFileChooserNative has glib call the D-Bus API (which is proxied inside the sandbox) for the FileChooser portal[2]. The backend running outside the sandbox (xdg-desktop-portal-gtk for GNOME/GTK; there are also backends maintained by KDE and wlroots developers) shows a file chooser and makes any file (since March 2020, there is also support for folders) selected by the user available inside the sandbox using the Documents portal.

Also the portal APIs are not specific to Flatpak. They can be used by any sandboxing framework that wants to benefit from the work already done to integrate them.

Some apps don’t use GTK or Qt, some apps (like GIMP) still use GTK 2, which doesn’t have GtkFileChooserNative, and some apps haven’t been ported from GtkFileChooserDialog to GtkFileChooserNative (or can’t be ported yet because of missing features in the latter). And the Documents portal doesn’t work perfectly for all use cases: There are issues with getting notified when a file is modified externally and with getting the path of the file outside the sandbox (to display it to the user, if that’s desired).

[1]: https://docs.gtk.org/gtk4/class.FileChooserNative.html

[2]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...