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