[Xquartz-dev] Proposal for PRIMARY and CLIPBOARD Copy/Paste
Jeremy Huddleston
jeremyhu at berkeley.edu
Fri Sep 12 12:38:46 PDT 2008
>> What do you mean toggle the option repeatedly to copy the proper
>> data?
>> That was never suggested. When the user does Edit->Copy in the
>> Gimp/Nedit/OpenOffice menu, then that triggers CLIPBOARD to be sent
>> to
>> PASTEBOARD. When they do X11.app's Edit->Copy, that sends PRIMARY to
>> the PASTEBOARD. There is no option to toggle X11.app's Edit->Copy to
>> do anything other than PRIMARY.
>
> That won't work well. What do we do with CLIPBOARD when the owner has
> changed?
You must've missed my earlier email:
Additionally, this particular issue can be solved by making pbproxy
greedy for CLIPBOARD. And we have:
On CLIPBOARD is stolen event:
if option_proxy_clipboard:
Copy data from CLIPBOARD owner to PB
if not option_proxy_pb_to_clipboard: // because this is done by the
PB change event handler if we are
Copy data from CLIPBOARD owner to pbproxy buffer
Claim ownership of CLIPBOARD
> As I have said before, that breaks X11/Tk apps, and probably others.
No, because pbproxy maintains ownership of CLIPBOARD.
> The selection owner is not required to send another XSetSelectionOwner
> request everytime the CLIPBOARD data changes.
Right, but it needs to when it isn't the owner.
> So the data may be out
> of sync with reality. The fact is that the data may only be generated
> on a paste/XConvertSelection request for normal X11 apps. For what
> we're doing that would be done by the "Copy Clipboard" menu item which
> causes pbproxy to call XConvertSelection.
Nope, just do it when someone else claims the CLIPBOARD away from
pbproxy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3040 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20080912/4f12cb20/attachment.bin
More information about the Xquartz-dev
mailing list