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