Bug 224257 - Add a new option to "move" as default with mouse dragging action without confirmation
Summary: Add a new option to "move" as default with mouse dragging action without conf...
Status: RESOLVED DUPLICATE of bug 154804
Alias: None
Product: digikam
Classification: Applications
Component: Usability-Mouse (show other bugs)
Version: 2.4.1
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-25 23:36 UTC by Dotan Cohen
Modified: 2022-04-11 00:30 UTC (History)
8 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2010-01-25 23:36:27 UTC
Version:            (using Devel)
Installed from:    Compiled sources

Please add an option for "move" as default mouse dragging action, without asking the user if he wants to copy. I never want to copy. Thanks!
Comment 1 caulier.gilles 2010-01-26 06:27:50 UTC
This is relevant of icon view D&D...

Gilles Caulier
Comment 2 Marcel Wiesweg 2010-01-26 19:07:52 UTC
I vote for WONTFIX. Press Shift while dragging.
Comment 3 Dotan Cohen 2010-01-26 21:01:20 UTC
> Shift while dragging.

It has been shown time and time again that automatics are more consistent at the drag strip. The only people who shift while dragging are nostalgics and wannabes. All the consistent sub-12 second cars run automatics.
Comment 4 Dotan Cohen 2010-01-26 21:04:55 UTC
This would be optional, not mandatory. Are there use cases in which the user copies enough where even having an option for move only would hinder him? I can name use cases in which the copy operation does not exist (namely, our family use case which is about 12-15 Digikam users at five homes, nobody uses move at all).
Comment 5 Brad Templeton 2011-10-10 22:55:40 UTC
I agree, I remain baffled by the UI.   I have always thought that digikam was to be a program for organizing photos, but this UI makes it extremely difficult to do that -- to the point that for anything but the most minimal organizing I will leave digikam and use other tools, then come back and have digikam re-scan.

Also, move should be instantaneous.   Now I don't know why it is so slow in digikam (it has gotten a bit faster of late) because in many programs it is something that takes a few 100ms at most.  However, if it is the case that digikam's architecture requires move to be slow, it would make sense to put it into a background thread so that people can then go about doing other moving and other actions while the move takes place.  (Not perfect but the current approach makes digikam hard to use as a photo organizer.)

For copying of course you can use the copy and paste tools.  Copying is much rarer in my experience, and because it is less often desired and even slower, it makes sense that it take a little more UI in order to make move easier.
Comment 6 caulier.gilles 2011-12-23 11:26:22 UTC
Dotan,

This file still valid using digiKam 2.4 ?

Gilles Caulier
Comment 7 Dotan Cohen 2012-01-11 09:13:53 UTC
Yes, this issue is still valid in the current Digikam. To reproduce:
1) Drag a photo from the main view into another album/folder
2) There is no step 2

It can be seen that the UI asks if the user wants to move / copy / set as thumbnail. I will never want to copy and I don't need the thumbnail question popping up every time I move a photo. Moving photos is a common operation, setting the thumbnail is a rare operation. Please make this dialogue optional or get rid of it!
Comment 8 caulier.gilles 2014-09-12 15:49:10 UTC
*** Bug 261564 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2020-03-10 17:19:53 UTC

*** This bug has been marked as a duplicate of bug 392531 ***
Comment 10 Nate Graham 2020-11-02 16:23:14 UTC

*** This bug has been marked as a duplicate of bug 154804 ***
Comment 11 Nate Graham 2021-02-16 16:31:07 UTC
*** Bug 432912 has been marked as a duplicate of this bug. ***