Add an "open in file manager" portal

[phw]

Note: Copied over from flatpak/xdg-desktop-portal-gtk#55 as it is not specific to GTK

Currently when using the FileChooser portal from a sandboxed application the applications gets a path in the fuse file system. This is great for accessing the app, but there are a couple of use cases where I would like to know the absolute path of the file as the user selected it:

1. I want to inform the user where the file was saved
2. I want to allow the user to open the file location ("show in file manager"), e.g. by calling to the org.freedesktop.FileManager1 DBus interface
3. I want to save the last used location for later use. E.g. the user saved a file to $HOME/Videos/Last Vacation, the next time the user saves I want to open the file chooser at the same location.

The first 2 use cases partially work with the current implementation, but the location used and shown to the user (e.g. /run/user/1000/doc/d7c87a14) is not what is expected and looks confusing.

The third use case is currently impossible for what I can tell.

Would it be feasible to also report the absolute path as set by the user back to the calling sandboxed application (in addition to the fuse path, which is the actual usable path for the application)? Does this have security implications I am not aware of?

[matthiasclasen]

I'm not entirely convinced that this is a good idea. I don't have any concrete security implication to point out, but it certainly makes i much more fuzzy whether the file chooser dialog is under user control or under application control.

I don't see a particularly strong need to inform the user about the file location either, since he just selected it himself in the file chooser.

And org.freedesktop.FileManager1 is not available to sandboxed applications.

[phw]

Would make some kind of "open in file manager portal", which would take care of the file path, make more sense then? Accessing a file after it was saved is a very valid and common thing. I rarely save a file and don't use it afterwards. Of course I know where I saved it, but navigating there means basically navigating to that location twice (once in the file chooser, and a second time to access the file).

E.g. Firefox' download function supports this, after you have saved a file you can open it in the file browser.

[hadess]

Would make some kind of "open in file manager portal", which would take care of the file path, make more sense then?

It might be useful, but it's only really useful if the file came from outside the sandbox.

Accessing a file after it was saved is a very valid and common thing. I rarely save a file and don't use it afterwards. Of course I know where I saved it, but navigating there means basically navigating to that location twice (once in the file chooser, and a second time to access the file).

That should be functionality offered by the file chooser portal. I think it's a fair assumption that it would remember the recently used directory on its own.

[phw]

It might be useful, but it's only really useful if the file came from outside the sandbox.

No, it is useful if the file is placed outside the sandbox, which is the case when you use the file chooser.

I think it's a fair assumption that it would remember the recently used directory on its own.

Yes, this is useful. But the file chooser remembering the location for later use is very different from opening the that location after saving.

[matthiasclasen]

In any case, if we decided to make the host path available inside the sandbox, this functionality would belong in the document portal. It already has an "Info" function, which maps back from the doc id to the path, but we don't make it available inside the sandbox.

[phw]

@matthiasclasen Yes, the document portal sounds like the right place for it.

But the more I think about this the more I feel this should be solved by an "open in file manager portal", which would work similar to the existing org.freedesktop.FileManager1. This would solve the common use case of showing a file location in the file browser. That use case is common to many applications, inclufing browsers to show downloaded files and many applications that offer some own but limited file management (some examples are e.g. GNOME Builder, Atom, MusicBrainz Picard and many more).

Apart from that use case I see little value in having the host path available in the sandbox. Only reason might be displaying the file path to the user, but that is probably seldom a good UI choice.