1st case : Right-click on a file on the desktop -> "Copy" Open Thunar on any folder In thunar, right-click : the "Paste" menu item is disabled, file from the desktop has not been selected for Copying 2nd case : Open Thunar on any folder Right-click on a file on the desktop -> "Copy" In thunar, right-click : "Paste" menu item is enabled, the file has properly been selected for Copying
I can reproduce it on my machine.
That might be a bug in Thunar but I'm not sure about it. Perhaps the X11 clipboard only works if the target app is running when stuff is copied into the clipboard? Need to further investigate this issue.
Thunar probably takes the ownership of the clipboard and starts watching it, and xfdesktop waits until the data is requested. But why don't you copy the uris to the clipboard in xfdesktop (for both copy and cut) and don't do stuff with ownership, that should work right? If the files are moved out the desktop folder, file monitoring will update the desktop.
*** Bug 3854 has been marked as a duplicate of this bug. ***
*** Bug 4301 has been marked as a duplicate of this bug. ***
*** Bug 5010 has been marked as a duplicate of this bug. ***
Maybe the patch in 7060 helps...
(In reply to comment #3) > Thunar probably takes the ownership of the clipboard and starts watching it, > and xfdesktop waits until the data is requested. But why don't you copy the > uris to the clipboard in xfdesktop (for both copy and cut) and don't do stuff > with ownership, that should work right? If the files are moved out the desktop > folder, file monitoring will update the desktop. I think you guys misunderstand how the clipboard works. You don't ever copy anything to the clipboard. Ever. There's no such thing as a clipboard as a data store. It's just an X selection. The 'copy' function is just your app saying "I have data that someone might be able to paste" by asserting ownership of the CLIPBOARD selection. If someone wants to paste, they check if there's a CLIPBOARD selection owner, see if the data advertised by the owner is a format the app can support, and then asks the owner of the selection to send it the data. This is why the (hack, IMO) of clipboard managers is (sometimes considered) necessary: if you "copy" some data in one app, and then quit that app, the data disappears with the app. A clipboard manager's job is just to sit there and watch for CLIPBOARD selection ownership changes, and preemptively request the data from the app, so the data is still available if the app quits. If Thunar is asserting CLIPBOARD ownership on startup, then that's a bug. It should only be doing that in response to a user action. It's also possible that the bug is simply that Thunar watches for SelectionNotify events to determine if 'Paste' should be enabled or not, but never does an initial check on startup to see if the clipboard is owned by an app that has data Thunar can paste. I really don't think this is a bug in Xfdesktop.
Over time I think various pieces of this problem are already fixed. We do have a proper working clipboard manager again (that does what you say: wait until the owner is quitting, then take the data and become the new owner). Also backported in a 4.8 stable release. The initial setup problem was also fixed some time ago in Thunar. So overall this might just work now.
Yeah, just tested this myself, and it works fine here. Hehe.