Version: 1.0.0 (using KDE 4.3.2) OS: Linux Installed from: Ubuntu Packages Currently (Digikam 1.0.0 final), dragging a photo from the album view photo grid or from the photo view' thumbbar to a Nautilus or Dolphin window moves the photo out of the album and into the folder. This behavior is reasonable but we need a way to copy (instead of move) the photo by Ctrl-dragging or Alt-dragging it from Album View or Photo View to a File Manager window (nautilus or dolphin) Likely Ctrl-drag for copy would be more intuitive Thanks
I'm Agree with this report. Providing a contextual menu with copy and paste is easy to do... Gilles Caulier
If you are (and you say you do) talking about dragging _from_ digikam _to_ any other app, than that's not our problem at all - the receiving app is responsible for providing such a choice. For me, dolphin indeed defaults to copying and cannot be convinced to move. I'm not sure why. Maybe it's using the digikam URLs and treating them as remote files. In any case, text/uri-list is available as well.
Hi Marcel, yes I refer about dragging pics out of Digikam and into a file manager window. Digikam behaves differently from other apps from some reason. When I drag a photo in digikam, the mouse pointer changes color and I see a "1" inside a little box besides the mouse pointer; there is also a small picture that shows up besides the mouse pointer as well. Intuitively, if I Ctrl-drag I would expect a "+1" inside the little box. All this does seem to be controlled by digikam. No other app in desktop behaves like this, even KDE Archiver tool. Also the reverse operation is a "move" by default and doesn't seem to offer "copy" by Ctrl-drag
The pixmap is indeed generated by digikam (you will see a "2" if you drag two photos), but we still just pass URLs and cannot control what the receiving application is doing with this. I dont know what we could do differently.
Just tested with Karmic's ark (package manager) and nautilus and dolphin. Somehow they are able to do both copy and move to both nautilus and dolphin. Also, you can drag or ctrl-drag files from dolphin to nautilus and viceversa and it just works fine. Copy or move, depending on "Ctrl" state. They both likely follow the freedesktop specs so maybe that's By default ARK copies - I think it would be great if digikam would also "copy by default" instead of moving. By moving by default, you may inadvertently lose pictures, it happened to me a few times while Viewing an album and trying to copy pics to a "For Print" folder. When you press shift then drag from ark, then it moves instead of copy. The icon changes (by default it draws a little "+", and when you shift-click it the arrow pointer changes to black and there is no "+". I think Ctrl-drag would be more intuitive for moving though, than shift-drag. "Ctrl" is what dolphin/nautilus use to select move or copy. Thanks
I agree that the experience you get in the end is not optimal, but the technical background is not correctly described: When you drag from digikam to dolphin, then digikam just puts a list of URLs in a QDrag object, Qt uses the platform standards for drag'n'drop, and it's dolphin that copies or moves. Digikam does nothing.
I have to correct my comment above: Dolphin offers me the menu to copy or move, and Ctrl and Shift work as expected. So I cannot reproduce. I have one tiny change, digikam otherwise starts a drag just like dolphin does.
SVN commit 1066014 by mwiesweg: When starting a drag, give Qt::IgnoreAction as default proposed action. This is how dolphin starts a drag as well. When dragging only one image, use it's icon as drag pixmap. CCBUG: 219908 M +1 -1 imagecategorizedview.cpp M +19 -1 imagedelegate.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1066014
Hi Marcel, Dolphin offers you the menu? what key combination/s are you using? I'm using karmic's default dolphin and I can't figure out how to copy instead of move. Also, is it possible to consering doing "copy by default" instead "move by default" like currently done? Thanks
Created attachment 39345 [details] dolphin context menu after drag from digikam
Ar, When I drag and drop from digikam (1.0.0) to dolphin (1.3 using KDE 4.3.4), on Debian, I receive a standard dialog with options of; move, copy, link or cancel. So I don't think it is a digikam setting that is causing your issue. Mark
> Also, is it possible to consering doing "copy by default" instead "move by > default" like currently done? Digikam does not default to "move" currently, it does not default to anything because digikam is not involved in any action when you drag from digikam to any other application. (digikam is responsible for what happens when you drag from anywhere to digikam). Furthermore, we are now using the same code as dolphin to start a drag, and all this is basically using Qt API. I dont think we can do any more here.
*** Bug 245835 has been marked as a duplicate of this bug. ***
Hi Marcel, You explaind what the technical background is why 'move' is the default action when a picture is dragged to nautilus / dolphin. I agree with Gilles and Ar that 'copy-by-default' or a contextual menu with the choice copy/move is prefered in this case. Beceause it is a photo-management application. You say you can't solve it. But I have the impression you agree that it would be nicer otherwise. Who in your opinion should we ask to improve this? gnome/kde? freedesktop folks? Thanks, Michiel
Well, from our side, with reading the Qt documentation, I can see no way to start the drag differently. I would be happy to improve this from our side, if there's a way which I did not see so far. I would suggest to open a bug for dolphin. If Peter Penz in turn tells you that dolphin is all right and it's digikam's fault, we can discuss the problem!
A simular bug for dolphin was just created by someone else. https://bugs.kde.org/show_bug.cgi?id=243657 I added a reference to this bug. https://bugs.kde.org/show_bug.cgi?id=243657#c1
*** Bug 313173 has been marked as a duplicate of this bug. ***