pbproxy - a copy/paste proxy for XQuartz
About pbproxy ------------- pbproxy is an application that transfers selections to/from X11 and the Mac pasteboard/clipboard. It supports copying strings, such as UTF-8, Latin-1, and Compound text. In addition to those, there is support for image copying, so you can copy images to/from the X11 Gimp (and other X11 applications that support image copying) and Mac applications. There is also support for copying and pasting very large amounts of data that used to previously fail. o Is it for me? If you currently experience problems with the existing copy/paste code in XQuartz or would like to copy images, then give this a try. pbproxy probably will solve the problems. o Downloads The home page of pbproxy and my XQuartz projects: http://people.freedesktop.org/~gstaplin/ This is what you want (the binaries with an installer): http://people.freedesktop.org/~gstaplin/pbproxy_test-10.tar.bz2 http://people.freedesktop.org/~gstaplin/pbproxy_test-10.tar.bz2.md5 o Sources The sources to pbproxy are currently in the git repository for the 1.4 apple branch of the X.org xserver. o Thanks Thanks to Apple, and especially (in no particular order) Jeremy Huddleston, and Jordan K. Hubbard this project has been improved, and made possible. o Feedback Please report problems/bugs and/or success stories to this xquartz-dev list, or gstaplin@apple.com Enjoy, George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/ http://people.freedesktop.org/~gstaplin/
George has been doing a great amount of work on this, so please give him the thanks he deserves and flood us with feedback, concerns, etc. Right now, this is being distributed as a separate binary for testing purposes. It includes an updated quartz-wm binary as well since the '--no-pasteboard' option in 2.3.1 wasn't fully functional. This updated quartz-wm will be part of 2.3.2_beta1, and I intend to integrate pbproxy's code into a thread on the X11 server itself. There is already a preference pane available for it which should cover most of the alternate behavior people have requested over the past year that I've been part of this conversation. Here is a snapshot of that configuration pane with the default options shown. If you think the behavior you want won't be covered by this, please let me know (note that I welcome formatting, text, punctuation, etc feedback as well). Thanks, Jeremy On Sep 22, 2008, at 11:39, George Peter Staplin wrote:
About pbproxy -------------
pbproxy is an application that transfers selections to/from X11 and the Mac pasteboard/clipboard.
It supports copying strings, such as UTF-8, Latin-1, and Compound text. In addition to those, there is support for image copying, so you can copy images to/from the X11 Gimp (and other X11 applications that support image copying) and Mac applications.
There is also support for copying and pasting very large amounts of data that used to previously fail.
o Is it for me?
If you currently experience problems with the existing copy/paste code in XQuartz or would like to copy images, then give this a try. pbproxy probably will solve the problems.
o Downloads
The home page of pbproxy and my XQuartz projects: http://people.freedesktop.org/~gstaplin/
This is what you want (the binaries with an installer): http://people.freedesktop.org/~gstaplin/pbproxy_test-10.tar.bz2 http://people.freedesktop.org/~gstaplin/pbproxy_test-10.tar.bz2.md5
o Sources
The sources to pbproxy are currently in the git repository for the 1.4 apple branch of the X.org xserver.
o Thanks
Thanks to Apple, and especially (in no particular order) Jeremy Huddleston, and Jordan K. Hubbard this project has been improved, and made possible.
o Feedback
Please report problems/bugs and/or success stories to this xquartz-dev list, or gstaplin@apple.com
Enjoy,
George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/ http://people.freedesktop.org/~gstaplin/ _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Nice I assume, certainly further ahead than my code which is still at the level of a bunch of CLI query tools for investigating. On Mon, Sep 22, 2008 at 12:23:09PM -0700, Jeremy Huddleston wrote:
and I intend to integrate pbproxy's code into a thread on the X11 server itself.
I'd rather you didn't - or if you do, allow it to be disabled. This way the behaviour is easily changeable. Also it allows for better bug isolation if something goes wrong, which it might if the code starts to do complex data manipulation. I've been investigating some of this, and found some interesting oddities in data presented by various X apps. In OOo swriter the target text/richtext isn't - it actually provides rtf. Also one of the targets gives the file contents - so it might be possible to provide drag'n'drop from X->Quartz, DnD in the other direction may be a bit more difficult. I've not run these binaries (they crash as I'm using Tiger), but from strings I managed to see all the atoms being used. An easy one to add is text/html, where OOo swriter offers this. One interesting possibility is using the Pasteboard translation services, at least the header files and samples in PasteboardPeeker make it look interesting. (I'd intended to support compound_text via an external translator). DF
On Sep 22, 2008, at 18:02, Derek Fawcus wrote:
Nice I assume, certainly further ahead than my code which is still at the level of a bunch of CLI query tools for investigating.
On Mon, Sep 22, 2008 at 12:23:09PM -0700, Jeremy Huddleston wrote:
and I intend to integrate pbproxy's code into a thread on the X11 server itself.
I'd rather you didn't - or if you do, allow it to be disabled.
Did you not see the screenshot in my email?
This way the behaviour is easily changeable.
How do you mean?
Also it allows for better bug isolation if something goes wrong, which it might if the code starts to do complex data manipulation.
well it's on a separate thread and doesn't actually mangle any data. The other thread would just be an X11 client thread and the communication between threads would still be X11 events (atleast for now).
On Mon, Sep 22, 2008 at 09:35:11PM -0700, Jeremy Huddleston wrote:
Did you not see the screenshot in my email?
No - I'm using mutt to read email, it is a pain to save graphical attachments, then find display them. Hmm - time to config some more handlers. Anyway, I've now seen the picture. I do not believe the 'copy menu item' should be disabled at the same time as any internal selection/pasteboard handling. This would seem to prevent use of an external pbproxy ala the current offering.
From nm on pbproxy, it seems that a WM extension symbol is being used for triggering the PRIMARY->CLIPBOARD copying and subsequent copying to pasteboard. I assume that 'Enable Syncing' would disable that menu and hence if the pbproxy functionality was embedded in the server, prevent the use of an external pbproxy.
Or would 'Enable Syncing' selected, with everything else deselected allow what I desire - the ability to run an external pbproxy equivalent? As to the 'Update Pasteboard when CLIPBOARD changes' option. As written this seems to imply that pbproxy will always act as a CLIPBOARD manager and take ownership of the CLIPBOARD selection after it has been changed. However I believe it should be possible to seperate the CLIPBOARD->Pasteboard proxying from pbproxy acting as a CLIPBOARD manager. I'm not sure if we need an option to disable updating PRIMARY when Pasteboard changes. Does anyone want this facility? All X apps will (I believe) acquire PRIMARY when they acquire CLIPBOARD, and so this would always be enabled. So I suspect these two should be combined in to a single 'Update PRIMARY and CLIPBOARD when Pasteboard changes' option.
This way the behaviour is easily changeable.
How do you mean?
Assume I want to extend its capabilities. e.g. add support for other target atoms <-> pasteboard UTIs, perform data transformations, etc.
Also it allows for better bug isolation if something goes wrong, which it might if the code starts to do complex data manipulation.
well it's on a separate thread and doesn't actually mangle any data. COMPOUND_TEXT <-> UTF8 (but probably using the X library code) The other thread would just be an X11 client thread and the communication between threads would still be X11 events (atleast for now).
Embedding it in the server, as described above, seems to gain little. We move from the existing, cut'n'paste fixed in quartz-wm, to cut'n'paste fixed in server. The only possible reason I can see to embed it in the server is to reduce context switch latencies, which compared to the data copying, and the context switches which cannot be eliminated (esp. if INCR occurs) seems a minor consideration. I believe pastboard promises can be used to defer copying (X11->pasteboard) until such time as pasting on the OSX side is attempted. Startup for a seperate process is easily handled in the same way that quartz-wm is started (currently the .xinitrc file). DF
On Sep 23, 2008, at 06:55, Derek Fawcus wrote:
I do not believe the 'copy menu item' should be disabled at the same time as any internal selection/pasteboard handling. This would seem to prevent use of an external pbproxy ala the current offering.
It would only be disabled if there were no handlers, so if you disabled that option for pbproxy and you had your own handler, it should still show up as enabled.
From nm on pbproxy, it seems that a WM extension symbol is being used for triggering the PRIMARY->CLIPBOARD copying and subsequent copying to pasteboard. I assume that 'Enable Syncing' would disable that menu and hence if the pbproxy functionality was embedded in the server, prevent the use of an external pbproxy.
There is no PRIMARY->CLIPBOARD copying. What do you mean by "that menu"? It's embedded in the server (as in that's where the bits are), but it's just like any other X11 client (like it is now with the bits separate). Toggling that main checkbox just toggles whether or not that thread is active... so you could just as easily disable it and use another option.
Or would 'Enable Syncing' selected, with everything else deselected allow what I desire - the ability to run an external pbproxy equivalent?
Enabling that and disabling everything else would cause the 'copy' menu item to be handled by pbproxy. You want to disable the 'Enable syncing' option.
As to the 'Update Pasteboard when CLIPBOARD changes' option. As written this seems to imply that pbproxy will always act as a CLIPBOARD manager and take ownership of the CLIPBOARD selection after it has been changed.
Yes.
However I believe it should be possible to seperate the CLIPBOARD-
Pasteboard proxying from pbproxy acting as a CLIPBOARD manager.
It is not possible without adding more complicated menu items. Please read through the thread on this list from last week for reasons why and if you're still convinced, I'd welcome your suggestions.
I'm not sure if we need an option to disable updating PRIMARY when Pasteboard changes. Does anyone want this facility?
Yes, I do. In Mail.app, copy URL. In xterm, wget <middle click>.
All X apps will (I believe) acquire PRIMARY when they acquire CLIPBOARD, and so this would always be enabled. So I suspect these two should be combined in to a single 'Update PRIMARY and CLIPBOARD when Pasteboard changes' option.
I just verified that Inkscape does not acquire PRIMARY when it acquires the CLIPBOARD. And even if you were right in most cases, I'd still want to give users the option of just proxying to one or the other.
This way the behaviour is easily changeable.
How do you mean?
Assume I want to extend its capabilities. e.g. add support for other target atoms <-> pasteboard UTIs, perform data transformations, etc.
Well, you have the source code. Go for it. I fail to see how putting the bits into the server and adding an option for running the thread or not will hinder your attempts.
Embedding it in the server, as described above, seems to gain little. We move from the existing, cut'n'paste fixed in quartz-wm, to cut'n'paste fixed in server.
Yes, so people get this proxying even if they don't use quartz-wm. They get it if they use XDMCP to connect to their linux box. They get it if that have a custom .xinitrc and aren't told they should exec this new binary.
Startup for a seperate process is easily handled in the same way that quartz-wm is started (currently the .xinitrc file).
However, your configuration isn't the only one out there. Some people start the server without xinit. Some people have an existing ~/.xinitrc which we can't update (unless they happen to source /usr/ X11/lib/xinit/xinitrc from their ~/.xinitrc. I want to support these other uses. --Jeremy
participants (4)
-
Derek Fawcus
-
George Peter Staplin
-
Jeremy Huddleston
-
Jeremy Huddleston