GNOME Bugzilla – Bug 771046
Cut & paste no longer works between desktop and window
Last modified: 2016-09-30 07:35:37 UTC
nautilus 3.21.91.1 Might be that things are still in flux in debian atm. I had to start nautilus-desktop manually to get my desktop back after the nautilus beta update. 1) Create a folder on the desktop 2) ctrl+x 3) open some folder 4) xtrl+v Expected: The folder gets moved there Actual: The folder gets copied; the source stays around. The same happens the other way around.
Oops, filed with the wrong product -> nautilus
Yes, it's the only drawback of the desktop split as far as I know. I will explain the problem: When dnd, we only mark for moving if it's in the same filesystem. In all other cases we just copy. Here, the same code path is reached, and since the desktop and nautilus are in different binary now the cache is not the same for both, so when checking the filesystem of the copied files we don't have the information ready, so we detect it as a different filesystem and therefore we just copy.
let's keep an eye for 3.22...
And you shouldn't need to run manually nautilus-desktop. That's done automatically by the desktop file.
Created attachment 336544 [details] [review] clipboard: rework clipboard handling We were using a custom clipboard monitor, due to some old behaviour in 2004 where not all X servers supported XFIXES, which allows to monitor global clipboard changes between processes, which are needed in Nautilus for copy, paste and link operations, and their availability check. Since Nautilus was a single process, it was working for most of the time. However recently we split the desktop in a different process, so we were not able to correctly set the GDK action for clipboard, since we were relying on sharing the same clipboard in the same process. In order to fix this, this patch reworks the clipboard handling to a more modern way, using the owner-changed signal present in XFIXES. This fixes the clipboard changing between the desktop and Nautilus and interproccess clipboard handling, fixes small corner cases, and in the way this patch makes the code design and ownership of clipboard more clearer.
Created attachment 336545 [details] [review] general: rework clipboard handling We were using a custom clipboard monitor, due to some old behaviour in 2004 where not all X servers supported XFIXES, which allows to monitor global clipboard changes between processes, which are needed in Nautilus for copy, paste and link operations, and their availability check. Since Nautilus was a single process, it was working for most of the time. However recently we split the desktop in a different process, so we were not able to correctly set the GDK action for clipboard, since we were relying on sharing the same clipboard in the same process. In order to fix this, this patch reworks the clipboard handling to a more modern way, using the owner-changed signal present in XFIXES. This fixes the clipboard changing between the desktop and Nautilus and interproccess clipboard handling, fixes small corner cases, and in the way this patch makes the code design and ownership of clipboard more clearer.
The issue was not the same dnd code path, but similar. So we coulf fix this one through reworking the clipboard handling of Nautilus Attachment 336545 [details] pushed as 55cf522 - general: rework clipboard handling
Thanks!