Re: portal drag and drop helpers and where to put them
On Tue, Apr 12, 2022 at 10:09 PM Volker Krause 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
Re: portal drag and drop helpers and where to put them
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). Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: portal drag and drop helpers and where to put them
On Tue, Apr 12, 2022 at 2:12 AM Aleix Pol wrote: > > Maybe the alternative would be to use the kdbusaddons for this? It > seems to me like there's no kcoreaddons things being done. I've thought about that but ultimately concluded kdbusaddons actually doesn't work for us. The way the technology works is that the sender and the receiver need to call a helper function to deal with the portal logic, if we had those helpers in kdbusaddons we'd need to have optional kdbusaddons dependencies on every drag and drop enabled application - it'd be super messy. HS
Re: portal drag and drop helpers and where to put them
Maybe the alternative would be to use the kdbusaddons for this? It seems to me like there's no kcoreaddons things being done. To make it more weird and complex, if we think of K*Addons frameworks an extension to their Qt* counterpart, I guess it should be abstracted behind something in QtGui, although I agree that in this case it would be rather messy to have it in KGuiAddons. 0'02€ from Aleix On Mon, Apr 11, 2022 at 11:46 PM Albert Astals Cid wrote: > > El dimecres, 6 d’abril de 2022, a les 13:28:50 (CEST), Harald Sitter va > escriure: > > 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 > > Not an expert on the matter but since noone is saying anything let me say > something to see if can spark some more discussion :D > > Personally I think an optional QtDBus dependency in kcoreaddons for this > purpose is acceptable. The systems that need portal-based-drag-n-drop require > dbus, so that's a no brainer for them. The systems where dbus is "strange" > like Android or Windows don't need this feature so it's more than fine to not > provide it. > > Cheers, > Albert > > > > > HS > > > > > >
Re: portal drag and drop helpers and where to put them
El dimecres, 6 d’abril de 2022, a les 13:28:50 (CEST), Harald Sitter va escriure: > 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 Not an expert on the matter but since noone is saying anything let me say something to see if can spark some more discussion :D Personally I think an optional QtDBus dependency in kcoreaddons for this purpose is acceptable. The systems that need portal-based-drag-n-drop require dbus, so that's a no brainer for them. The systems where dbus is "strange" like Android or Windows don't need this feature so it's more than fine to not provide it. Cheers, Albert > > HS >
portal drag and drop helpers and where to put them
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 HS
