Created attachment 7373 Patch file for xfdesktop-file-icon-manager.c When moving a file from the desktop to any of the non-thunar file managers that I've tested, (Nemo, Caja, and Nautilus) rather than the file being moved like you would expect, it is copied to wherever you dragged it to in the file manager leaving you with two of the same file. I'm new to programming/hacking, but after messing around with the source code I managed to fix the problem for me. I say I'm new to programming because I have no idea what the full ramifications of the changes I've made are yet, but the changes I did make were VERY simple so I don't see them having much impact. I've pasted a patch file showcasing the differences between the original file (xfdesktop-file-icon-manager.c) and the one I changed to fix the issue. (xfdesktop-file-icon-manager-modified.c) Basically, all I did was modify the file "xfdesktop-file-icon-manager.c" in "src" by changing the first two instances of "GDK_ACTION_COPY" to "GDK_ACTION_MOVE". That's it. I'm not sure if this bug exists in the newest version, (using Xubuntu 16.04) but I think it's safe to assume it is since according to the xfce-mirror on github, this file hasn't been modified for 3 years.
I just tried to drag & drop files from xfdesktop to thunar and caja, and in both cases, the file is copied, not moved. Tested with xfdesktop 4.12 / thunar 1.6 and xfdesktop git / thunar git. I don't know what is the expected behavior. Maybe Andre or Eric have an advice.
AFAIK dragging files from/to the same volume should always move them and copy them when dragging to another volume, Thunar 1.7.0 is working as expected here, in both cases. But dragging files to Nemo and Nautilus always copy them, dragging from them to desktop the files are moved if the destination is on the same volume. With regards to the patch, it seems simple, needs testing between different File Managers and taking into account the same and different volumes cases. In the end, it's Eric's call.
Replacing GDK_ACTION_COPY with another GDK_ACTION_MOVE in a bitwise OR operation is redundant. Also, this does not look like a proper fix to me. Is it even still needed? Please test with up-to-date components.
(In reply to Theo Linkspfeifer from comment #3) > Replacing GDK_ACTION_COPY with another GDK_ACTION_MOVE in a bitwise OR > operation is redundant. Also, this does not look like a proper fix to me. You're right, this just removes the possibility to copy by holding the ctrl key. > Is it even still needed? Please test with up-to-date components. Still reproducible with xfdesktop from git master, nemo 4.0.6 and nautilus 3.32.1. I can even reproduce this when dragging from thunar to nemo/nautilus, but not the other way around. It seems both components have this flaw.
Does not appear to be a bug in xfdesktop/thunar unless you see the lack of support for the "x-special/gnome-icon-list" drop type as a bug. Without it even Nautilus copies a file when moved to another Nautilus window. Probably the same for Nemo. Lastly, Caja uses a renamed version of the drop type: "x-special/mate-icon-list". Based on my test results it seems that the mentioned file managers simply prefer the copy action when forced to process "text/uri-list". https://gitlab.gnome.org/GNOME/nautilus/blob/master/src/nautilus-canvas-dnd.c#L68
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfdesktop/-/issues/38. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev