On Tuesday 20 March 2012 14:16:10 Marcus Harrison wrote:
> I'm fully against this idea, and I'll explain why.

Please let's postpone the "what is better"-discussion: The question is whether there are enough users around here to justify a non-default option to provide a way to do a dropping without context-menu.

To make it clear: I agree to your points and hence I don't plan to change the default behavior in Dolphin; so the default action on dropping will always be to open the "Copy to/Move to/Link to"-menu.

> Currently, when the user drags and drops, the user is given a choice to copy, 
> move or link, via a menu. This menu also shows the user which keyboard button 
> to press if they want any of the other operations.
> I don't think it's wise to just guess what the user wants to do, especially 
> given that whether you are moving between folders in the same filesystem or 
> across file systems is the only way you're going to guess this behaviour. My 
> standard behaviour for managing files on a camera is to use a smaller memory 
> card (2GB) on the camera, then move all files from the memory card to the 
> computer so I have room to take more photos. However, I'll only copy music off 
> an external hard-drive onto my machine, if I'm going to give the external 
> hard-drive back to my friend. In my situation, the logical "default" is to 
> move files from device to device, and use a keyboard key to copy for the odd 
> occasion when I need it.
> 
> The most important aspect to me, though, is discoverability:  bringing the 
> menu up by default explicitly tells the user how to perform a copy/move 
> quickly. Copying/moving automatically does NOT tell the user how to change 
> this behaviour, bring up a menu or create a link instead - most users won't 
> know, and only the technologically comfortable will bother to explore. We'd be 
> turning the situation from one where every user knows how to use the various 
> pieces of functionality to one where most users don't know and would have to 
> turn to Google to find out. This is exactly the situation with Windows and Mac 
> OS - with KDE it's completely unnecessary.
> 
> And finally, if it really bothers some users that a menu pops up, they can 
> always hit "Ctrl" to copy and "Shift" to move. These buttons never change - 
> unlike they potentially might if drag 'n' drop is context sensitive, and even 
> if they don't, it's still more guessing on the user's part.
> 
> On Tuesday 20 March 2012 11:44:50 Peter Penz wrote:
> > On Tuesday 20 March 2012 11:22:37 Jonathan Marten wrote:
> > [...]
> > 
> > > But disc partitioning is less apparent on Unix than on
> > > Windows - there are no drive letters, and filesystems can be mounted
> > > anywhere, so it is not possible for the user to tell just by looking
> > > at pathnames whether the operation will be a copy or a move.  Having
> > > data moved instead of copied, without being aware of this, could
> > > result in data loss.
> > 
> > I fully agree to this but I think before a discussion is done whether making
> > this default or whether the copy/move behavior is done dynamically, we
> > should wait for David Faure (= maintainer of libkonq) whether having an
> > option for not showing a "Copy to/Move to/Link to"-menu at all will be
> > accepted.
> > 
> > Although I'm usually very skeptical about adding new options, I initially
> > thought that adding this option would be OK. Now after checking the
> > duplicates/votes for this report I'm surprised about the low numbers - it
> > seems the demand for this is quite low (or I missed hidden duplicates in
> > bugs.kde.org). Anyhow lets wait for David's feedback first.
> > 
> > Cheers,
> > Peter
> 
> Marcus Harrison
>