[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