Open file chooser in folder containing specific file

[hadess]

It would be useful for applications to be able to pass a sandboxed file path they have access to, from the outside, for the file chooser to open in, eg.

If /home/user/Documents/foo.txt is known as /tmp/xdp-test-263CJ0/test.txt inside the sandbox, we should be able to pass that path, so that the file chooser opens with the /home/user/Documents/ directory pre-selected.

@grulja, does Qt already have an API for this? Closest for GTK is gtk_file_chooser_set_current_folder(), which is not going to work here.

[rugk]

Would be useful e.g. for any software that edits a file. Video-trimmer is a good example: https://gitlab.gnome.org/YaLTeR/video-trimmer/-/issues/24

It improves the UX a lot when you open a file, edit it and then the directory to save the file to is the same directory as the one, where you've opened it.

[2xsaiko]

Qt has QFileDialog::setDirectory or setDirectoryUrl for this.

In the same vein, allow pre-selecting a file to allow for "Save As" type actions to select the file the document is currently saved as.

[Mikenux]

Can't this be done by having the file chooser remember the last folder opened for a given application?

[Mikenux]

(at least when a file was opened from it)

[2xsaiko]

No, in a lot of cases the application wants to open different directories under different contexts (e.g. for different file types), or set a path explicitly, e.g. "Save As" in the Kate editor opening the dialog in the directory of the file currently selected in the editor.

[Mikenux]

Indeed, what I said does not cover all cases.

Another thing I said (but in another issue) is to have something that translates sandboxed file paths (/run/user/1000/...) to normal file paths (/home/user/Documents/... ).

Something like:

The application sends a sandboxed file path -> a Flatpak PathTranslator Helper translates the sandboxed path to a normal path -> The file chooser opens the correct location.

Does something like this make sense? (note that I'm not a developer, I'm just trying to come up with ideas)

[Mikenux]

Or given that a sandboxed file is linked to the unsandboxed one, maybe it's possible to use that link?

[CellyC]

I just want to say I just installed Ubuntu 22.04, it's a fresh install on a new computer. And I got the same bug. Are there been progress on the subject? Do we know what's causing it?

[fedelibre]

@CellyC Can you make an example of what is not working?

I'm on Fedora 37 Silverblue. In GNOME Text Editor (org.gnome.TextEditor), when I try to open a new file, the file chooser starts from the directory of the last opened file.

$ rpm -q xdg-desktop-portal
xdg-desktop-portal-1.15.0-4.fc37.x86_64

[CellyC]

Whenever I save a file on firefox, no matter where I saved it the last time, firefox wants to save it in /run/user/1000/randomNewFolder. The folder is new for every file I save so /run/user/1000/ is quickly getting filled with folders.

If I save my file somewhere else (like my "download" file) I still see it appear in that run/user/1000 folder. If I delete it from the run/user/1000 folder it also disappears from the place I saved it in, even if it's on a different partition. So it's scary because it means I could lose all my files that are saved on supposedly safe partitions if something happens to run/user.

I deleted my firefox profile and made a new one and it didn't stop it from happening. I have no idea what I can do to make it stop.

[CellyC]

I just found what is happening !

Firefox cannot "access" most partitions on my computer. By choosing a directory on /MyPartition I force it to put things there. But the next download he again wants to put it somewhere it can access. When I save things in /home there is no problem.
So the problem is most probably with snap.

I'll save everything in /home until I find what is happening. It didn't happen on my other computer, which had about the same partitions setup... But at least I have a workaround for now !

[GeorgesStavracas]

I think this was fixed by #1020 - please reopen if that's not the case!

[adhami3310]

I don't think this is resolved. The MR mentioned is related to OpenURI, which is not related to this issue.

[Mikenux]

@adhami3310: I think this is #1045. Apps must use the new method. However, according to https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.FileChooser.xml, "The portal implementation is free to ignore this option."

[adhami3310]

@adhami3310: I think this is #1045. Apps must use the new method. However, according to https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.FileChooser.xml, "The portal implementation is free to ignore this option."

That one specifies current folder. This is not known since the app developer only knows a specific file that lives in the sandboxed environment. If there's a way to get the correct host folder from a sandboxed file then it should be resolved.

[Mikenux]

The sandbox path is translated to the host path.

[adhami3310]

Oh I see! Thank you for the help.

[Mikenux]

I realized it is for the file chooser, so I assume it will open the file chooser and not the file manager. The OpenURI portal seems more appropriate, but not the OpenFile method, since it is about opening a file. In this same portal, there is the OpenDirectory method, which corresponds to what is wanted here given its description. So yes, this issue may not be fixed.

@GeorgesStavracas, @matthiasclasen: I think clarification is needed. Thanks!

[Mikenux]

Sorry, ignore my previous comment.