Ability to transfer files by dnd and copy/paste

[TingPing]

If you drag a file into a sandboxed application the path will be on the host where you won't have access.

[matthiasclasen]

This will probably need work in the compositor: it needs to recognize that the drop target is sandboxed, and make sure that the dropped files are accessible to it (by exporting it in the document portal, if necessary)

[matthiasclasen]

Or maybe this should be up to the drag source ?

[alexlarsson]

In X, is anything but the two interating apps involved in the operation at all?

[alexlarsson]

I guess in the wayland case the compositor is more involved?

[matthiasclasen]

In the wayland case, the compositor is the middle man for any of these interactions. In X, yes. this is direct client-to-client communication by means of selections

[matthiasclasen]

One way to go about this would be to only enable it in wayland, and argue that X is unsuitable for sandboxing...

[alexlarsson]

We could make Gtk do the l export on the dropping side if it somehow detects that the peer is a flatpak app. However, we would then need some kind of X property on toplevels for flatpak app, and I don't really know how you would do that.

I guess we need something similar for the wayland case too. Or i guess the compositor knows the pid of the app and can tell if its sandboxed.

[matthiasclasen]

A fairly elegant way to handle would be to introduce a mime type for this. Instead of requesting text/uri-list, as we currently do, we could request text/x-document-portal-uri-list or somesuch when in a sandbox, and gtk could learn to treat this by:

1. export the files in the document store
2. put the document paths in the request
3. treat it like text/uri-list otherwise

This should work in both X and Wayland, with no protocol changes.

[matthiasclasen]

Seems that I've overlooked that we do need to know the target app-id in order to export the files, and that probably has to be provided by the compositor, to be trustworthy. So a fixed mime-type won't work. We could do something like text/uri-list;appid=org.gnome.Recipes, but since we will have to rewrite the mime-type in the compositor anyway, we might as well handle the exporting in the compositor.

[alexlarsson]

Could be a very general compositor feature though, like it mapping toplevel to appid. Is there a way to guarantee you're talking to the X compositor or WM though and not some random client?

[alexlarsson]

Alternatively we could just send the entire file over the dnd protocol. Or is that a horrible idea?
Mimetype "application/x-file-contents".

[TingPing]

I DnD 7GB movie files all the time, I cannot imagine that ending well.

[matthiasclasen]

https://gitlab.gnome.org/GNOME/gnome-shell/issues/418

[muelli]

Alternatively we could just send the entire file over the dnd protocol.

that'd probably work for us. We have relatively small files in the range of a few kilobytes.

[matthiasclasen]

You can do that today. Just use a different mime type and send the content

[muelli]

more precisely, I want to drag an attachment from Evolution running on the host into an app running inside a flatpak container. So I'm not controlling the sending side in this case. Is it still possible to send the file contents somehow?

[matthiasclasen]

Not without changing the sender

[matthiasclasen]

The existing file forwarding functionality of flatpak can be pressed into service for this.
Assuming the shell manages a text/uri-list copy/paste operation and is about to deliver it to
application XYZ. running

flatpak run --command=/usr/bin/echo --file-forwading XYZ @@ file1 file2 ... @@

will produce a rewrittten list of files on stdout that can be passed on to XYZ. Example:

flatpak run --command=/usr/bin/echo --file-forwarding org.gnome.Todo @@ /etc/passwd ~/test.c @@
/run/user/1000/doc/cca9e5f3/passwd /home/mclasen/test.c

This is of course pretty inefficient, and we should add a way to do this rewrite without launching a container.

[matthiasclasen]

https://github.com/matthiasclasen/flatpak/tree/document-forwarding has a command that shows exactly what a compositor needs to do to rewrite a list of files.

[matthiasclasen]

See flatpak/flatpak#2065 for some musings about the best way forward.

[muelli]

cool. Let me link it here so that I will remember in the future.
is there a Gtk4 example, by any chance?

[matthiasclasen]

When the support is built into the tookit, it should be entirely transparent - you just select a file, drag it or copy it to the clipboard, and under the covers, GTK talks to the portal to make the right thing happen. Of course, it will only work if both sides of the transfer support this, so getting it into more tookits will be important.

[dreua]

We should find somebody to back port it to gtk3.

Any update on this? Do I understand correctly that it is currently not easily possible to support dnd or copy/paste through portals in Gtk3? Would it be reasonable to create a new bug for progress on the backport?

[utkb]

I have similar problem in Ubuntu 20.04 with Flatpak package, i can't send files from file manager's send menu to Geary. There is a "Attach not found" error message. I am not sure wheather this is same problem or not.

[dreua]

@utkb: Your problem could be related but it's not productive to discuss it here. Please create an issue against Geary or the Geary Flatpak if that has it's own issue tracker. Include a link to this issue just in case the developers/maintainers are not aware of it.

[mjog]

It's not a bug in Geary, please don't file a bug about this there.

[dreua]

@mjog @utkb Sorry, I didn't do proper research and just assumed that it wouldn't be a known limitation in Geary. In general, users should report any issues against the packages first so that the respective developers can have a look. In this case this has already happened and @utkb's Geary problem is indeed blocked by this bug.

[dreua]

There wont be a Gtk3 port, will it?

[TingPing]

While its probably technically possible for a very motivated person to get it working in GTK3 its very unlikely to happen. The DND support in GTK4 is very different to GTK3 and it would be non-trivial to port those patches over.

[Mart-Bogdan]

That's strange that all discussion is around GTK, but not a word about Qt.

I've encountered same issue with Qt based app: telegram-desktop

Saving files with save dialog is also wired, but that's another issue, I think. And it at least kinda work.

[TingPing]

Nobody here is a developer for Qt. You'll have to discuss it with them.

The portal is documented here: https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.FileTransfer

[Mart-Bogdan]

Like, I mean do there issue exist, or something?

As I understand Flatpak should bring unified descrop experience across distros + security.

P.S. Thanks for link

[Mart-Bogdan]

Adds files to a session. This method can be called multiple times on a given session. Note that only regular files (not directories) can be added.

Wow. So directory Drag'n'Drop don't work with flatpak?

[Mart-Bogdan]

To confirm current status.

It works only if both client and server apps are GTK4?

Perhaps someone know some aoo that definitely work? So I could check.

[Mart-Bogdan]

Yeah, they have issue for Qt: https://bugreports.qt.io/browse/QTBUG-91357

[dreua]

BTW, the Qt issue also lists a dedicated issue for GTK3. Unfortunately there is no progress either: https://gitlab.gnome.org/GNOME/gtk/-/issues/3094