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

[Ivan Vučica]

Someone might implement such a backend without a native clipboard. For  
example, a framebuffer-based mobile UI based on GNUstep.

If it is feasible to have gpbs as an additional backend, that might be  
interesting. But if a backend is easily replaceable, it may also be a  
non-issue.

An additional benefit of having pasteboard server as a separate  
process under x11 is that pasteboard server can provide data to other  
x11 apps even if source gnustep app is terminated.

Regards,

Ivan Vučica
via phone

On 8. kol. 2011., at 19:53, Eric Wasylishen <address@hidden>  
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