[Cloudef]

I've always wondered why file picker has to be so tightly integrated into GUI toolkit. Separate program outputting the selected path(s) sounds like much nicer design, and makes it easier to implement alternative file pickers.

[prussian]

I believe that is the purpose of the xdg portals specification.

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

[Cloudef]

Not really

>The FileChooser portal allows sandboxed applications to ask the user for access to files outside the sandbox. The portal backend will present the user with a file chooser dialog.

In addition it being a dbus api for communicating outside a sandbox

[mid-kid]

It was indeed designed to be a portal for escaping the sandbox, but this has the nice side-effect of allowing the file dialog to be implemented by whatever program is called through D-Bus. This is already being used in KDE distributions to show the KDE file picker in firefox, where it would've required patching firefox back in the day.

[prussian]

Not really how? https://github.com/ranchester2/nautilus-as-file-chooser-poc This is a standardized GTK workflow that works in and out of flatpak.

[Cloudef]

I was under impression the backend has to implement all of the API to do that. Nice to know it's enough to have dbus service that listens to a single call. I might do this to replace file picker on my machine. It's still baffling however, how fork + exec <-> pipe can't be used for this. Especially considering that under all that dbus cruft the PoC essentially does this: https://github.com/ranchester2/nautilus-as-file-chooser-poc/...

[BrightGlow]

Using fork and exec with a pipe is not going to work within a sandbox. That "cruft" is necessary for the thing to work...

[Cloudef]

I get why they invented this for flatpak (Even though it still could be done with processes and namespaces), but my original point was wondering why they did not originally use fork, exec and pipe.