portal drag and drop helpers and where to put them

Albert Astals Cid aacid at kde.org
Mon Apr 11 22:46:15 BST 2022


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
> 






More information about the Kde-frameworks-devel mailing list