D26484: Add KIO::DropJobFlag to allow manually showing the menu

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Hi. I just came across dropping random data (in my case an image) into file views not working, i.e. not creating any new files due to no more data in the QMimeData instance referred to in the DropJob.
  
  Looking into the details, it seems this is due to the flaw of KIO::DropJob being async, but the QDropEvent (which got a respective comment) and even more the QMimeData it exposes (which has no comment, but just a helpless QPointer wrapper) is not defined to outlive the QWidget drop event handler call. And both at least X11 and Wayland protocol seems to negotiate things by the drop serving instance only offering a list of MIME types, next to the copy or move action, and only on the reply of the drop consumer actually deliver the data of the selected MIME type.
  
  My naive reaction to this would be to use some QEventLoop inside KIO::drop() for the user interaction to query "Copy or Move" and "Which format?", then extract the very data from the QMimeData, before returning to the Qt drop event handler call from which KIO::drop() would be called.
  
  But the method added here, DropJob::showMenu() and their usage would not be fixed by this. Anyone around still involved with this who could work on this from their use case POV? Or at least give some thoughts on this?

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D26484

To: trmdi, #frameworks, davidedmundson, elvisangelaccio, mart, dfaure
Cc: kossebau, ngraham, broulik, anthonyfieroni, kde-frameworks-devel, LeGast00n, cblack, michaelh, ahmadsamir, bruns, vkrause
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20240509/5292bede/attachment.htm>