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.
Drag and drop doesn't work with Konqueror for me either, although it says otherwise in the KSnapshot "What's this" popup.
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
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.
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!
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)
Thanks for clarification, I could reproduce it now.
@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?
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
@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?
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 ;)
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...
Created attachment 33928 [details] dolphin patch that enables the feature (but the resulting file is always empty because of the Qt bug/behavior)
Created attachment 33936 [details] Very puzzling. A standalone Qt testcase works :(
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.
We can't simply do a file drag as the image need not have been saved to disk, so there's no corresponding file.
... 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...
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.
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.
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.
David, is there any news on this issue?
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...
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.
http://qt.gitorious.org/qt/qt/merge_requests/860 submitted.
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
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
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 :-)
@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).
(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.
Thanks for letting us know!