Drag & Drop support

[Perkolator]

It seems that drag & drop of files to running programs is only working if the file is located under the ~/Downloads folder. Files drag & dropped from elsewhere create errors/crash programs.

Obviously this is because of the nature of Flatpak applications, and thus impossible to fix (unless opening the whole filesystem to Bottles Flatpak).

What at least could be done, is to add a - use drag & drop of files to running programs outside of the user "~/Downloads" folder (or something like that) "case" to the Expose directories documentation section, under the Despite this, there are some cases where you may want to explicitly expose directories to the Flatpak, e.g.: text.

EDIT: Forgot to add that it would be good to mention that a :ro read-only override is not enough. With :ro, a file could be drag & dropped to a program, but saving a file from that doesn't work. I tested this with 1) SubtitleEdit; drag & drop of a ".srt" file worked, but saving it didn't work, 2) gMKVExtractGUI; drag & drop of a ".mkv" file worked, but extracting a track from the video file (saving to a new file) didn't work. Read+write override is needed.

[orowith2os]

Drag and drop is already supported, now we're just waiting on more xdg-desktop-portal improvements. This should be documented in the online docs, if not done already. From what I see, that's already sufficient, but feel free to make a PR to improve it; it should be easy enough.

[Perkolator]

Drag and drop is already supported, now we're just waiting on more xdg-desktop-portal improvements.

Hmm. Drag & drop to running programs work only from under the ~/Downloads folder by default, and that's only because installing Bottles Flatpak sets a xdg-download read+write "file access" permission by default.

Are there some upstream updates coming that would allow drag & drop to work for the whole user filesystem without actually opening the whole filesystem with a Flatpak permission (which is not what is wanted at all, if I have understood correctly by reading the docs & some of the issues here)?

This should be documented in the online docs, if not done already. From what I see, that's already sufficient, but feel free to make a PR to improve it; it should be easy enough.

Sorry but I don't understand what you're saying here. Maybe your claim of "d&d is already supported", is confusing me. I don't see anything in https://docs.usebottles.com/flatpak/expose-directories page that mentions needing to give Flatpak permissions to be able to drag&drop files to programs (outside the user download folder).

The page says: It makes use of portals to let you open and save files in other directories. Creating a Drive in a bottle (=creates a portal) doesn't allow drag&drop of files to a running program from that (or any) bottle. Flatpak permission is needed.

The page goes on to say:

Despite this, there are some cases where you may want to explicitly expose directories to the Flatpak, e.g.:
- let the Importer find windows prefixes from other managers directories;
- use the file chooser provided by the runner to open/save files in your system, outside the sandbox.

I proposed that this section would be amended to include:
- use drag & drop of files to running programs outside of the user "~/Downloads" folder (or something like that, my English isn't that great..)

Actually, I just realized that the above:

- use the file chooser provided by the runner to open/save files in your system, outside the sandbox.

shouldn't be there at all. Isn't the "Manage Drives" (=portals) actually what the user should do in that situation? Not add Flatpak permissions. The docs pages are really outdated.. maybe the situation changed at some point (Flatpak permission were needed at the beginning but then the portals system was added?) but the docs were not updated?

[Perkolator]

@orowith2os Did you see my response?

[orowith2os]

Yes I did. As I said, it is already supported, and only needs improvements on the portal side of things.

[Perkolator]

Ok. Is there an issue about portals, or about permissions in general? Now that #413 was suddenly closed..