FileChooser: Portal can only open, not just choose files

[sophie-h]

This issue is basically an upstreaming of https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/26

Currently, OpenFile() is designed to make files/folders available as readable in the sandbox. Following problems exist with the current design/definition

1. The definition does not mention how error handling works. IIRC KDE shows an error when a file is not readable. GNOME currently behaves the same way as if the user has nothing selected. The latter means, there is no way for the app to handle the error.
2. There is no way to select files/folders that are not readable. My use-case is a backup application where you want to exclude folders that are not readable anyways. However, that's not possible with the OpenFile() portal.

I see two things that probably should happen:

1. Either clarify that portal implementations should handle errors for unreadable folders/files and implement them where missing. Or, add error feedback to the portal that can be handled by the app. This is also a question for designers.
2. I think in some sense the OpenFile() portal behaves correctly since it is supposed to make the file/folder available in a readable form to the app. However, I think there are enough use-cases where the app just wants the path. This will especially be true if we really start using the file portal on the host system. Maybe we need a flag for OpenFile() or a ChooseFile() function that only passes the path through? (Unclear if it should pass a path through, that's not available in the Flatpak.)

[matthiasclasen]

My take on this: the portal can only open files, since thats what it says on the label (literally, in the filechooser button): "Open".

The fact that the backends currently let you select files or folders that the frontend then refuses to return to the caller feels like a quality-of-implementation issue in the affected backends. They should only let the user select objects that are acceptable.

[ZanderBrown]

Files vs folders, a classic UNIX tale…

Given how disperate the implementations are it would seem we still have a documentation issue, or alternatively this is a feature request.

Also Matthias Clasen's downstream comment seems to imply this should work with folders:

In any case, those permissions are enforced by the portal frontend when adding the files/directories to the document store.

And if I understand correctly, the main issue seems to be that implementations don't know (or don't tell apps?) when that adding-to-document-store failed? Though it's possible I'm not following.

[sophie-h]

And another day on which, someone got bitten by the problem because we dropped the most basic features from our ecosystem. https://gitlab.gnome.org/World/pika-backup/-/issues/138#note_1600670

[matthiasclasen]

Trying to clarify the purpose of this portal: the file chooser portal is about taking files (or folders) that are available (ie redable) by the user, and making them available (ie readable) for the caller. Therefore, it can by definition only return readable files/folders, and it cannot operate on files/folders that are not readable by the user.

[sophie-h]

it can by definition only return readable files/folders

Not sure where that definition comes from but never mind.

I made some suggestions on how to cover the use cases that are currently not possible via portals. What are your alternative suggestions?

[swick]

To me it seems like the only case where getting a reference to some path which can't be opened is desired is when the app has access to the host filesystem. Could we maybe add a flag to the filechooser which can only be used when the app host access to the host fs where the filechooser returns a host path instead of adding it to the document store?

[swick]

Another thought... if the app already has access to the host filesystem, shouldn't it be possible to use the gtk filechooser instead to select files even if the can't be opened?

[ssokolow]

To me it seems like the only case where getting a reference to some path which can't be opened is desired is when the app has access to the host filesystem. Could we maybe add a flag to the filechooser which can only be used when the app host access to the host fs where the filechooser returns a host path instead of adding it to the document store?

In my experience, granting --filesystem=something automatically causes the chooser to start to return host paths for files within that grant.

Another thought... if the app already has access to the host filesystem, shouldn't it be possible to use the gtk filechooser instead to select files even if the can't be opened?

Please don't. I export GTK_USE_PORTAL=1 on my KDE desktop to finally have KDE file choosers on non-KDE apps that aren't yet offered through Flatpak and we've wanted it for so long that there used to be a somewhat crashy hack named KGtk which monkey-patched KDE dialogs into GTK applications using LD_PRELOAD.

[sophie-h]

the filechooser returns a host path

That's totally possible, and that's what most people have suggested. But it has been rejected so far. That's why I'm asking the maintainers to suggest an alternative solution.