[Xquartz-dev] pbproxy - a copy/paste proxy for XQuartz
Jeremy Huddleston
jeremyhu at apple.com
Tue Sep 23 09:16:54 PDT 2008
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
-------------- 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/20080923/05219d61/attachment.bin
More information about the Xquartz-dev
mailing list