portal drag and drop helpers and where to put them

[Harald Sitter]

On Tue, Apr 12, 2022 at 10:09 PM Volker Krause <vkrause at kde.org> wrote:
>
> On Mittwoch, 6. April 2022 13:28:50 CEST Harald Sitter wrote:
> > https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/212
> >
> > To get sandboxed apps to work with drag and drop we need to have drags
> > take a roundtrip through xdg-desktop-portal and unfortunately enough
> > that needs to happen by passing an open fd into the relevant API,
> > presumably to demonstrate that the sender actually can open the file
> > they want to send. To that end the sender  would call a helper
> > function to extend qmimedata with the relevant transfer context and
> > the receiver needs to reverse that to get to (potentially in-sandbox)
> > paths again.
> >
> > On top of that there's also the fact that we can drag and drop remote
> > sources so we kind of also need to first mount remote urls into the
> > file system using kio-fuse :(
> >
> > All in all it's very broad in scope and requires a dependency on
> > qtdbus so I'm not sure kcoreaddons is necessarily the place for this
> > to live, at the same time we have related API here already so in the
> > interest of keeping related things together kcoreaddons kind of makes
> > the most sense. In particular since the existing helper function for
> > the receiver already existed meaning we get a lot of applciations to
> > support this without further changes.
> >
> > Thoughts would be much appreciated
>
> Is this potentially something for the QPA level? That would seem conceptually
> like the right place and it isn't affected by dependency considerations.
>
> (This might be an entirely stupid suggestion of course, my understanding of
> both the portal interface and the low-level drag/drop handling is extremely
> minimal).

It's a good thought.

The way the Portal works is that we need to pass in file descriptors,
so we need to explicitly open the paths and then pass the fds over
dbus to the portal. That has two implications:

a) to my mind it seems a bit fishy to implicitly open files behind the
developers back
b) because of the open() our applications first need to fuse potential
remote files into the filesystem (e.g. if you drag smb://foo/bar
dolphin would first need to kio-fuse mount that url, then open() the
mount point, then pass that open fd to the portal) - this seems a bit
questionable to have in a QPA

HS