Context-sensitive drag 'n' drop in KDE.

Marcus Harrison marcus at harrisonland.co.uk
Tue Mar 20 13:16:10 GMT 2012


I'm fully against this idea, and I'll explain why.

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




More information about the kfm-devel mailing list