If you try to drag and drop a file from a Thunar window to the desktop, you should be able to hold the Ctrl key to copy the file, or Ctrl+Shift to create a symbolic link. Instead, the file will be moved regardless of which modifier keys you press. Steps to reproduce: 1) Create a file in your home directory. 2) Open up your home directory in a Thunar window. 3) Drag and drop the file from the Thunar window to the desktop while holding down Ctrl+Shift. Actual results: the file is moved from your home directory to the desktop. Expected results: a symbolic link to the file is created on the desktop, leaving the file itself still in your home directory. Platform: Ubuntu 12.04
Created attachment 4997 decide on move/copy action before items have been dropped When files have been dropped as uri-list, the callback function xfdesktop_file_icon_manager_drag_data_received() decides whether they should be copied or moved depending on their location, ignoring the selected drag action. The comment preceding the code in charge reads: /* If the user didn't pick whether to copy or move via * a GDK_ACTION_ASK then determine if we should move/copy * by checking if the files are on the same filesystem * and are writable by the user. */ I don't think this is the right place to make this decision, because even if the user didn't pick the action via GDK_ACTION_ASK, it could have been chosen using modifier keys and it has already been indicated by the mouse cursor. I've attached a patch where the move/copy action is proposed in the drag-motion stage, e.g. before the items have been dropped, and can be overridden by modifier keys.
Dennis, Thanks for the patch! It's been pushed to master: http://git.xfce.org/xfce/xfdesktop/commit/?id=63df50d249bba0522b5bd2f0c23748ae38e9026b
Created attachment 5000 fixes: HTTP URL performance issue / wrong action proposed Upon further testing, I've found some issues with my patch: 1) Dragging an HTTP URL from a web browser (i.e. Chromium) kills performance. 2) The proposed action when dragging a file to a volume is "move" when it should be "copy". This new patch fixes these issues by 1) only checking "file" URLs for move/copy (others wouldn't make sense anyway) 2) adding an optional output parameter "suggested_action" to xfdesktop_icon_get_allowed_drop_actions() and making the implementing methods set it according to their resp. preference. The suggested actions are: folder: move if writable else none volume: copy if writable else none file: copy (run) if executable else none trash: move I hope everything now works as expected.
Dennis, Pushed your latest patch to master: http://git.xfce.org/xfce/xfdesktop/commit/?id=7ff0477814096554ccd6c14a56c851bd1c32166b Thanks again!
Since everything you reported and fixed was merged in I'm closing the bug. Thanks again for the patches.