xdg-desktop-portal
xdg-desktop-portal copied to clipboard
flatpak
Open file chooser in folder containing specific file
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.
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.
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.
Can't this be done by having the file chooser remember the last folder opened for a given application?
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.
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)
Or given that a sandboxed file is linked to the unsandboxed one, maybe it's possible to use that link?
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?
@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
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.
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 !
I think this was fixed by https://github.com/flatpak/xdg-desktop-portal/pull/1020 - please reopen if that's not the case!
I don't think this is resolved. The MR mentioned is related to OpenURI, which is not related to this issue.
@adhami3310: I think this is https://github.com/flatpak/xdg-desktop-portal/pull/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: 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.
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!