Re: [PATCH] Same filesystem drag-and-drop of a readonly file should gracefully degrade to a "copy"

["Nelson Benítez León" <nbenitezl gmail com>]

2008/10/2 Mike Rooney <mrooney gmail com>

On Thu, Oct 2, 2008 at 6:56 AM, Nelson Benítez León <nbenitezl gmail com> wrote:
> Hi!, I've posted a new patch in here[1] , the bug is about when drag'n'drop
> a file from a readonly location like "/etc" to some user folder, with the
> patch we change the drop action to COPY instead of MOVE, because the later
> causes an error due to "/etc" being readonly ...
>
> [1] http://bugzilla.gnome.org/show_bug.cgi?id=314139
>
> PS. Patch also attached to this mail.
>

Sounds like a great feature! What are the implications of this for
someone who isn't aware that the source is read-only, however? Do they
still get the "move" cursor when they press the appropriate keyboard
modifier? It seems like if not it could be frustrating to a user
thinking they are pressing the wrong key or otherwise making another
mistake.

I think the optimal solution would be to show the same cursor (ie, the
cursor should represent the intention) but present a dialog after the
file[s] are copied explaining they were only copied and not moved.
This way people attempting to move files for functional purposes
(security, privacy, trying to prevent something from running, et
cetera) will be aware that they didn't accomplish their goal, which
could be rather important. The current behavior achieves this
awareness so in that since there is a regression.

   The user receives feedback on the emblem of the dragged icon, it changes from the move emblem to the copy one, that's enough in my opinion, the extra dialog you mention just annoys the normal user, who don't want to read or think about these things, we are just doing a sane default action for him, same as when you currently drag and drop from CDROM to user folder, it also defaults to copy for similar reasons.