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

[Eric Wasylishen]

Hi Fred,

On 2011-08-08, at 2:54 PM, Fred Kiefer wrote:

> 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 don't think limited types on X11 is a problem since it's totally extensible, 
so we can always define private types if we need to, and provide fallback data 
using common types. When I copy from OpenOffice.org, for example, it provides 
the standard "application/rtf" which we can use, but also some private OOo XML 
types which we can ignore. 

btw, here is a handy Python script for examining the clipboard contents (in the 
first answer:) 
http://stackoverflow.com/questions/3261379/getting-html-source-or-rich-text-from-the-x-clipboard


However, one drawback I found is there in only one Win32 Clipboard, so in order 
to support other pasteboards like ruler/font/find panel/user created 
pasteboards on windows, we would still need something like gpbs to emulate more 
pasteboards. It could be done in-process in the applications, though.

> 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.

Agreed. 

cheers,
Eric

> 
> 
> 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
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev