pbproxy-13 (a pasteboard 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. Changes since release 11 --------------------- 13 - Thu Sep 25, 2008 Remove the backup files from the distribution that I mistakenly left when building the tarball. Add a release_checklist.txt and the interactive test suite to the tests directory. --------------------- 12 - Thu Sep 25, 2008 I fixed the STRING property, so that now rxvt can copy/paste, as well as other apps that only support the Latin-1/STRING. I fixed the usage of the NSString cStringUsingEncoding: - it doesn't NUL terminate the string, which lead to a bus error in some cases. So, we use lengthOfBytesUsingEncoding: to get the length in bytes instead of strlen(). Add a -force option to ./install.sh. For example: sudo ./install.sh -force Document this new flag in the README.txt. ----------------------------------------- Please report bugs to this list or gstaplin at apple.com George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/ http://people.freedesktop.org/~gstaplin/
I spent so much time writing the message and checking details that I forgot the links. :-) Here is the tarball with binaries: http://people.freedesktop.org/~gstaplin/pbproxy_test-13.tar.bz2 http://people.freedesktop.org/~gstaplin/pbproxy_test-13.tar.bz2.md5 Quoted George Peter Staplin <georgeps@xmission.com>:
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.
Changes since release 11
--------------------- 13 - Thu Sep 25, 2008
Remove the backup files from the distribution that I mistakenly left when building the tarball.
Add a release_checklist.txt and the interactive test suite to the tests directory.
--------------------- 12 - Thu Sep 25, 2008
I fixed the STRING property, so that now rxvt can copy/paste, as well as other apps that only support the Latin-1/STRING.
I fixed the usage of the NSString cStringUsingEncoding: - it doesn't NUL terminate the string, which lead to a bus error in some cases. So, we use lengthOfBytesUsingEncoding: to get the length in bytes instead of strlen().
Add a -force option to ./install.sh. For example:
sudo ./install.sh -force
Document this new flag in the README.txt. -----------------------------------------
Please report bugs to this list or gstaplin at apple.com
Oh my goodness, I just noticed I had this in my postpoed list and had not sent to the list. Hi George, First thanks for the great work with copy/paste. I was able to test it out and even copy a small image, fantastic. I have a suggestion for an improvement. Since the 8-bit does not work well with X11.app I used Xvnc and Screen Sharing to run those set of programs. I have some some scripts I use to sync-up the OS X paste board and the X11 selection which I have as menu items in my .twmrc: $ head bin/xpb bin/pbx ==> bin/xpb <== #!/bin/sh # X selection to Paste-buffer xsel -p | pbcopy ==> bin/pbx <== #!/bin/sh # Paste-buffer to X selection pbpaste | xsel -c That works a lot of the time but not for really big amounts of data and sometimes characters get messed-up. So I have to do things like cat into a file or /dev/null, use terminal.app as a go between, scp, etc - ie lots of anying workarounds in various cases. It would be really nice if pbproxy detected the un-presence of the AppleWM extentsion and still ran in the background. I am guessing it is only doing that for syncing-up with the preferences and handling the edit -> copy menu and keyboard shortcut. You would not need to worry about the first case and the second could be handled with a SIGUSR1 handler. Then people that don't use X11.app could have this great tool. I would simply put a killall -USR1 pbproxy in my .twmrc for example. Again thanks for all the very good and appreciated work. mzs On Thu, 25 Sep 2008, George Peter Staplin - georgeps@xmission.com wrote:
About pbproxy
On Oct 17, 2008, at 08:51, xquartz-dev.5.mzs@spamgourmet.com wrote:
It would be really nice if pbproxy detected the un-presence of the AppleWM extentsion and still ran in the background.
If the AppleWM extension is not present, then we don't have a way of knowing when we gain focus or when you do a copy. This might be possible once we change the implementation to work with things like: pbcopy < some_file [[middle click]]
I am guessing it is only doing that for syncing-up with the preferences and handling the edit -> copy menu and keyboard shortcut.
as well as knowing when we leave or enter X11.app, so we can proxy to/ from Pasteboard.
You would not need to worry about the first case and the second could be handled with a SIGUSR1 handler. Then people that don't use X11.app could have this great tool. I would simply put a killall -USR1 pbproxy in my .twmrc for example.
You should be able to SIGHUP it to reload prefs (that's how quartz-wm was, and I think that code survived to pbproxy, but I'm not 100% certain of that... if not, I'll put that in later). --Jeremy
Hi Jeremy, Keep in mind that all of this is with Xvnc not X11.app as the server through this reply. mzs On Fri, 17 Oct 2008, Jeremy Huddleston - jeremyhu@apple.com wrote:
If the AppleWM extension is not present, then we don't have a way of knowing when we gain focus or when you do a copy. This might be possible once we change the implementation to work with things like:
By gain focus you mean X11.app gains focus, right? By do a copy you mean some one does Edit -> Copy or the keyboard shortcut, right?
as well as knowing when we leave or enter X11.app, so we can proxy to/from Pasteboard.
I see no problem with pbproxy making the X11 selection match the contents of the Pasteboard whenever the PB changes regardless of if it is the frontmost app or not. If it is not possible for a background app in OSX to watch the PB then the alternative would be for it to do the PB -> X11sel upon getting a SIGUSR2. Then I would have two commands in my .twmrc (just like I do now) one from PB -> X (USR2) and the other X -> PB (USR1). That might even be a neat feature for X11.app (implemented through apllewm instead of signals though), the worthless Edit -> Paste could be enabled to do the PB -> X only when a user wanted it (that might warrant a different menu item text though). I personally like how I need to do the Edit -> Copy to be able to paste something from an X11 program into an OSX one. I sometimes annoys me that after I do an Edit -> Copy in some OSX app I paste an unexpected gigantic blob of text into my xterm window sitting at the bash prompt ;)
You should be able to SIGHUP it to reload prefs (that's how quartz-wm was, and I think that code survived to pbproxy, but I'm not 100% certain of that... if not, I'll put that in later).
Cool, just like a daemon. It would be nice to have an arg to pbproxy to specify an alternative config file, with an item in there to specify a new name it could exec itself into so killall would only effect one in case some one was running say 2 Xvnc sessions and one instance of X11.app all with their own pbproxy. mzs
On Oct 17, 2008, at 11:17, Mike Sliczniak wrote:
Hi Jeremy,
Keep in mind that all of this is with Xvnc not X11.app as the server through this reply.
mzs
On Fri, 17 Oct 2008, Jeremy Huddleston - jeremyhu@apple.com wrote:
If the AppleWM extension is not present, then we don't have a way of knowing when we gain focus or when you do a copy. This might be possible once we change the implementation to work with things like:
By gain focus you mean X11.app gains focus, right?
Right, but in your case, knowing when Xvnc gains focus... so we won't know when that happens. We use the focus-in/focus-out events for proxying to/from Pasteboard (this is what is happening currently. I think we need to fix this to copying immediately).
By do a copy you mean some one does Edit -> Copy or the keyboard shortcut, right?
Right, but the 'copy on select' functionality could still work since it uses XFixes and not AppleWM.
as well as knowing when we leave or enter X11.app, so we can proxy to/from Pasteboard.
I see no problem with pbproxy making the X11 selection match the contents of the Pasteboard whenever the PB changes regardless of if it is the frontmost app or not.
Right, that's how it should be... otherwise pbcopy and pbpaste will not behave as expected.
If it is not possible for a background app in OSX to watch the PB then the alternative would be for it to do the PB -> X11sel upon getting a SIGUSR2. Then I would have two commands in my .twmrc (just like I do now) one from PB -> X (USR2) and the other X -> PB (USR1).
That could work... if you're this keen on the idea, send me a patch... since my hands are a bit full of higher priority issues than making pbproxy work for Xvnc (harsh, yes.. but I'd rather be honest with you than not).
That might even be a neat feature for X11.app (implemented through apllewm instead of signals though), the worthless Edit -> Paste could be enabled to do the PB -> X only when a user wanted it (that might warrant a different menu item text though).
Eh... I think that's adding too much option-bloat.
I personally like how I need to do the Edit -> Copy to be able to paste something from an X11 program into an OSX one. I sometimes annoys me that after I do an Edit -> Copy in some OSX app I paste an unexpected gigantic blob of text into my xterm window sitting at the bash prompt ;)
Well... you're the one who copied it =p The whole point is automatic synchronization. Again, if you want to send a patch for a hidden option (set with defaults instead of the preference pane) to enable the functionality here, I'll certainly consider merging it for you.
You should be able to SIGHUP it to reload prefs (that's how quartz- wm was, and I think that code survived to pbproxy, but I'm not 100% certain of that... if not, I'll put that in later).
Cool, just like a daemon. It would be nice to have an arg to pbproxy to specify an alternative config file, with an item in there to specify a new name it could exec itself into so killall would only effect one in case some one was running say 2 Xvnc sessions and one instance of X11.app all with their own pbproxy.
Again... all good options... just a bit out of the realm of "neccessary" and entering the realm of "candy" ... but I'd certainly merge anything like this if you send some patches. --Jeremy
Quoted xquartz-dev.5.mzs@spamgourmet.com:
Oh my goodness, I just noticed I had this in my postpoed list and had not sent to the list.
Hi George,
Hi mzs,
First thanks for the great work with copy/paste. I was able to test it out and even copy a small image, fantastic.
You're welcome. I'm glad it works.
I have a suggestion for an improvement. Since the 8-bit does not work well with X11.app I used Xvnc and Screen Sharing to run those set of programs.
I have some some scripts I use to sync-up the OS X paste board and the X11 selection which I have as menu items in my .twmrc:
$ head bin/xpb bin/pbx ==> bin/xpb <== #!/bin/sh
# X selection to Paste-buffer xsel -p | pbcopy
==> bin/pbx <== #!/bin/sh
# Paste-buffer to X selection pbpaste | xsel -c
That works a lot of the time but not for really big amounts of data and sometimes characters get messed-up. So I have to do things like cat into a file or /dev/null, use terminal.app as a go between, scp, etc - ie lots of anying workarounds in various cases.
I can imagine how that would be tricky.
It would be really nice if pbproxy detected the un-presence of the AppleWM extentsion and still ran in the background. I am guessing it is only doing that for syncing-up with the preferences and handling the edit -> copy menu and keyboard shortcut. You would not need to worry about the first case and the second could be handled with a SIGUSR1 handler. Then people that don't use X11.app could have this great tool. I would simply put a killall -USR1 pbproxy in my .twmrc for example.
It should work without AppleWM in that way. The sources to pbproxy/xpbproxy are available in the 1.4 apple branch of the freedesktop xserver git respository. If you could implement the changes necessary, without breaking the code when it's used with AppleWM that would help.
Again thanks for all the very good and appreciated work.
I'm glad it's useful to you and others. It's a group effort, so I can't take all of the credit. :) George -- http://people.freedesktop.org/~gstaplin/
Hi, On Fri, 17 Oct 2008, George Peter Staplin - georgeps@xmission.com wrote:
It should work without AppleWM in that way. The sources to pbproxy/xpbproxy are available in the 1.4 apple branch of the freedesktop xserver git respository. If you could implement the changes necessary, without breaking the code when it's used with AppleWM that would help.
Both Jeremy and you don't see any real problems preventing this, so I wil give it a shot. The problem will be finding some free time. mzs
participants (4)
-
George Peter Staplin
-
Jeremy Huddleston
-
Mike Sliczniak
-
xquartz-dev.5.mzs＠spamgourmet.com