[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