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
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
