|
From: | Fred Kiefer |
Subject: | Re: X11 copy/paste and drag-and-drop |
Date: | Mon, 08 Aug 2011 12:39:35 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 |
On 08.08.2011 00:09, Eric Wasylishen wrote:
Hey, I did some investigating of why copy/paste from X11 apps to GNUstep doesn't work well (only plain text was working), and drag-and-drop doesn't work at all for me between GS and non-GS apps. I fixed one set of bugs in xpbs a few days ago, so now you can copy and paste rich text from OpenOffice.org to Ink, as long as you copy the text in OpenOffice to the clipboard _before_ Ink/gpbs are started. The remaining problem is that we aren't updating the list of types on the pasteboard when the selection changes in non-GS applications. I committed part of a fix for this; now xpbs.m is notified when the selection owner changes (e.g. from plain text in gnome-terminal to rich text in OpenOffice.org.) However, it doesn't yet do anything with this information. My current idea is something like: - xpbs receives notification that the selection owner changed - xpbs calls a private NSPasteboard method -invalidateCurrentTypes, which means the next time someone calls -[NSPasteboard types], we need to ask X11 for the currently available types (as implemented by -[XPbOwner availableTypes] I'm not really sure how to implement this as I don't fully understand the interaction between gpbs.m and NSPasteboard.m, but I think the approach would work.
One possible way to solve this is to reuse the (currently unused) ivar _ownedByOpenStep, setting it at the beginning of the method -xSelectionClear and clearing it at the end again. In -pasteboardChangedOwner: we would then check this flag and do nothing if it is set. All other uses of this ivar should be removed then. Not the most elegant solution, but it should work for now. It would be better if the code in gpbs would just not send a -pasteboardChangedOwner: method back to the original owner. There is code in there that tries to achieve this, we should try to find out why it isn't fully working. It may be that the problem is with the use of the -lostOwnership method. I don't quite understand what is going on there.
I also debugged a drag-and-drop session from Abiword to Ink, and the place where it fails is [[NSPasteboard pasteboardWithName: NSDragPboard] types] returning nil, when it should have returned the types being dragged. So, it's essentially the same underlying problem as copy/paste, since the dragged data is just another X11 selection like PRIMARY or CLIPBOARD.
A long time ago I worked with Wim Oudshoorn, trying to analyse what is wrong with our XDnD implementation. In the end the result was that quite a lot is broken and that the current architecture of the code wont do. If I remember correctly we concluded that we need to give up the idea of handling XDnD within the pasteboard service and will have to move the data transfer code over to the standard X event loop. The exact details are lost to me, but I think it was about the window the data will be send to. For some reason the XdndProxy mechanism didn't seem to work for us. I will have to dig out these old mails to fill in more details.
Fred
[Prev in Thread] | Current Thread | [Next in Thread] |