[Xquartz-dev] pbproxy-13 (a pasteboard proxy for XQuartz)

Jeremy Huddleston jeremyhu at apple.com
Fri Oct 17 11:50:56 PDT 2008


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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3221 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20081017/56f45737/attachment.bin 


More information about the Xquartz-dev mailing list