Bug 159337 - drag and drop of raw data doesn't work anymore
Summary: drag and drop of raw data doesn't work anymore
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2008-03-15 01:50 UTC by Elektro Schock
Modified: 2018-02-01 21:30 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Unimplemented drag&drop between KSnapshot and Dolphin (167.85 KB, image/png)
2008-11-28 15:59 UTC, Dario Andres
Details
dolphin patch that enables the feature (but the resulting file is always empty because of the Qt bug/behavior) (1.29 KB, patch)
2009-05-22 22:01 UTC, David Faure
Details
Very puzzling. A standalone Qt testcase works :( (2.35 KB, text/x-c++src)
2009-05-23 03:10 UTC, David Faure
Details
New test-case that shows the problem with QMetaObject::invokeMethod (3.89 KB, application/x-bzip)
2009-08-20 15:33 UTC, Tobias Koenig
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Elektro Schock 2008-03-15 01:50:24 UTC
Version:           0.8.1 (using 4.0.2 (KDE 4.0.2) "release 7.1", compiled sources)
Compiler:          gcc
OS:                Linux (i686) release 2.6.22.17-0.1-default

While a drag and drop functionality seems to be implemented, drag and drop of the screenshot item to a dolphin window does not work. This behaviour looks unintuitive. In fact it would make a lot of sense to get rid off the save/as functionality and just apply drag and drop.
Comment 1 Tobias 2008-06-16 14:41:11 UTC
Drag and drop doesn't work with Konqueror for me either, although it says otherwise in the KSnapshot "What's this" popup.
Comment 2 Dario Andres 2008-08-27 18:42:41 UTC
Qt: 4.4.0
KDE: 4.1.1 (KDE 4.1.0 (4.1 >= 20080722))
KSnapshot: 0.8.1
in ArchLinux i686:

I can reproduce this bug. However, Drag&Drop works dropping the image in GIMP
Comment 3 Richard Moore 2008-08-27 23:28:44 UTC
This seems like more of a flaw in dolphin - the views in the KDE 4.x konq are shared with dolphin too which explains why the same result is seen there.
Comment 4 Peter Penz 2008-10-01 23:43:30 UTC
I cannot reproduce this issue. Could you please explain the steps to reproduce it? I'm not sure what you mean with "screenshot item"... Thanks!
Comment 5 Dario Andres 2008-11-28 15:59:19 UTC
Created attachment 28889 [details]
Unimplemented drag&drop between KSnapshot and Dolphin

BTW. This happens on KDE 4.1.3 and also in today KDE4.2trunk (~ 890066)
Comment 6 Peter Penz 2008-11-28 18:24:25 UTC
Thanks for clarification, I could reproduce it now.
Comment 7 Peter Penz 2008-12-01 21:19:44 UTC
@David: From a users point of view I fully agree to this bug report, but from a developers point of view I'm unsure how we should proceed. When an image is dragged from KSnapshot, QMimeData returns true for QMimeData::hasImage(). So in this case Dolphin would require to save the image manually with the help of QImage::save(). This feature also seems not to be supported in Konqueror for KDE3... Is it possible that there is a easier way to fix this issue?
Comment 8 nmatthew 2008-12-11 19:58:46 UTC
I can't use dolphin, or any other file manager to drag and drop files anywhere. 
It is non functional. I can't move files to or from a USB drive. 
This makes my system rather useless.
Any ideas?
Thankss
Comment 9 FiNeX 2009-01-15 09:25:40 UTC
@nmatthew: your problem is not the one described on this bug. If you are still having problems on a newer KDE4 version (like 4.2 RC), please open a new bug report.

About dragging an image to dolphin: this bug shouldn't be considered a WISH?
Comment 10 David Faure 2009-05-22 19:34:17 UTC
FiNeX: no because it's a regression. Worked in konqueror-kde3 indeed.
Just found the code for it: KonqOperations::doDrop, the main else block. Code still there in kde 4. Will have a look why it's not called.

Peter: no need for QImage::save, it's ksnapshot's job to export the data in multiple formats, including PNG and JPEG, and it does that indeed (as konq-kde3 shows). All we have to do is to make sure doDrop is called ;)
Comment 11 David Faure 2009-05-22 21:56:19 UTC
Damn. The KDE side was easy, but Qt forgets the QMimeData contents by the time the messagebox is closed :-(
I need to make a standalone Qt testcase of the problem and hope QtSw can fix that bug...
Comment 12 David Faure 2009-05-22 22:01:48 UTC
Created attachment 33928 [details]
dolphin patch that enables the feature (but the resulting file is always empty because of the Qt bug/behavior)
Comment 13 David Faure 2009-05-23 03:10:21 UTC
Created attachment 33936 [details]
Very puzzling. A standalone Qt testcase works :(
Comment 14 Kai Krakow 2009-05-31 13:21:29 UTC
I reported #194495 before I was pointed here. Maybe that should have been made a duplicate of this instead closing as "invalid"...

My idea was: Couldn't ksnapshot simply export the drop as a file object so standard file drag-drop operations apply? It should make it work with almost any application, shouldn't it?

Of course one needs to set a default file format (png, jpg, ...) in the settings dialog.
Comment 15 Richard Moore 2009-05-31 23:14:14 UTC
We can't simply do a file drag as the image need not have been saved to disk, so there's no corresponding file.
Comment 16 David Faure 2009-06-04 13:41:21 UTC
... and if ksnapshot makes a temporary file, then "undo" in konqueror/dolphin would re-create that temporary file instead of just deleting the new file, etc.
(Well it might do that already, which is a known bug in kio/paste.cpp, but at least it's fixable there with a bit of effort :)

If anyone wants to help, feel free to test both my patch and my standalone testcase to see if you can confirm my findings. If so, then the next step is (e.g. for me) to debug further into Qt...
Comment 17 Kai Krakow 2009-06-05 18:07:54 UTC
I wouldn't bother if that temporary file would be created in kde's tmp folder it has per user. When undoing it this simply results in the file being pushed back into the tmp folder which really doesn't hurt that much (imho). It is cleared anyway after a while or by regulary cleanup processes.
Comment 18 Paul van Erk 2009-07-31 17:14:39 UTC
I'm experiencing the same bug. Got sent from my 202101 bug to another one and this one. It used to work fine, but I believe stopped working in 4.3 for me. At least I've had it working in some 4.2.x versions. I could drag from ksnapshot to an e-mail compose window from kmail. I now have to save the screenshot that I don't even want to keep first and then go through the attachment file dialog in kmail.
Comment 19 Tobias Koenig 2009-08-20 15:33:13 UTC
Created attachment 36297 [details]
New test-case that shows the problem with QMetaObject::invokeMethod

The problem is triggered by the usage of QMetaObject::invokeMethod() in conjunction
with the QMessageBox.
Comment 20 Mark 2010-09-19 02:46:20 UTC
David, is there any news on this issue?
Comment 21 David Faure 2010-10-14 21:33:26 UTC
OK, this is more complex than I thought. Dropping of text data (from a webpage for instance) works fine (with my dolphin patch applied). It's only image data that doesn't work. I'll debug that...
Comment 22 David Faure 2010-10-15 01:23:41 UTC
Tobias's testcase crashes because the QMimeData is getting deleted when we go back to the eventloop; but this is not what happens in KDE. We have a modal dialog, but that's fine, it doesn't delete the QMimeData [at least since Qt respects event loop levels for deleteLater]. The invokeMethod only happens when showing the copy/move/link popup, which isn't the case when dropping raw data.

The bug is tied to the handling of image data. QTBUG-4110 too. And it looks like the fix I just made for that bug, fixes this one too.
Comment 23 David Faure 2010-10-15 01:53:43 UTC
http://qt.gitorious.org/qt/qt/merge_requests/860 submitted.
Comment 24 David Faure 2010-10-15 02:13:57 UTC
SVN commit 1186021 by dfaure:

Enable dropping of raw data, like one could do in KDE3. It's actually working fine with text data for instance,
only image data is still an issue due to bugs in Qt. This will be in KDE 4.6.
CCBUG: 159337


 M  +5 -4      draganddrophelper.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1186021
Comment 25 David Faure 2010-10-15 19:10:56 UTC
I found the bug, after much more digging. It's a timer inside Qt (which discards old XdndDrop transactions, in the sending application. So if the user takes more than 5 seconds to choose a file format, the data is not available anymore! 

I just reported a Qt bug about this, with testcase. http://bugreports.qt.nokia.com/browse/QTBUG-14493
Comment 26 David Faure 2012-10-13 06:42:08 UTC
QTBUG-14493 just got fixed in Qt 5.

So the next step is... let's come back to this issue once we use Qt 5 :-)
Comment 27 Frank Reininghaus 2012-11-06 07:18:21 UTC
@David: Thanks a lot! Is any action on our side needed when we use Qt 5? If not, I would like to close this report (UPSTREAM).
Comment 28 Julian Steinmann 2018-02-01 20:27:25 UTC
(In reply to David Faure from comment #26)
> QTBUG-14493 just got fixed in Qt 5.
> 
> So the next step is... let's come back to this issue once we use Qt 5 :-)

After over 5 years, we are now indeed using Qt 5 ;) I just tested this with Dolphin 17.12.1 & Spectacle 17.12.1. The drag and drop functionality is working perfectly -> bug can be closed.
Comment 29 Richard Moore 2018-02-01 21:30:07 UTC
Thanks for letting us know!