[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.

[BrightGlow]

Because the goal was to make an API that works the same both inside the sandbox and outside the sandbox. Edit: It wouldn't work with just processes and namespaces because you need a way to talk to a resource with a privilege level above the current mount namespace.

[Cloudef]

Right, the child process can't escape the sandbox. I guess IPC here is the only sane choice.