Re: X11 copy/paste and drag-and-drop

[Fred Kiefer]

This idea will surely make it easier to write a correct implementation 
for XDnD.

There is one big drawback to it, after the rewrite every copy&paste and 
drag&drop operation will go via the system clipboard. I expect that to 
be a lot slower then our current DO based version and of course plenty 
of pastboard types wont be supported by X (and it will be even worse for 
Windows). We only should do this rewrite when we have a proper concept 
of transferring all our internal types over the X and Win32 native 
clipboard.

I think that switching to the 10.6 API would be a good point to do this. 
Still we should make sure that we fall an in-process fallback in place 
for the most common case where copy&paste or drag&drop happen within the 
same application.

Fred


On 08.08.2011 19:53, Eric Wasylishen wrote:
> Another point David reminded me of:
> While working on this, I didn't really see the point of running gpbs in a 
> separate process. It seems like the main use would be for running on a system 
> that didn't have a native clipboard system, which we don't do.
>
> If I update the NSPasteboard to match the 10.6 API, I would be tempted to get 
> rid of gpbs, and refactor the existing x11/windows clipboard code from xpbs.m 
> and win32pbs.m to the respective server backends (XGServer/Win32Server).
>
> Does anyone see any problems with this approach?
>
> -Eric
>
>
> On 2011-08-07, at 4:09 PM, 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.
> >
> >
> > 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.
> >
> > Regards,
> > Eric