[Xquartz-dev] Proposal for PRIMARY and CLIPBOARD Copy/Paste

[Jeremy Huddleston]

On Sep 11, 2008, at 16:18, George Peter Staplin wrote:

> Quoted Jeremy Huddleston <jeremyhu at apple.com>:
>
>> Ok, my original response was over iPhone, so I couldn't really
>> elaborate too much...  here's the basic logic/pseudocode for how this
>> should work:
>>
>> Event PRIMARY changed (ie someone selected new text):
>> 	if option_proxy_on_select:
>> 		PRIMARY -> PB
>>
>> Event X11.app Edit->Copy menu item:
>> 	PRIMARY -> PB
>>
>> Event CLIPBOARD changed:
>> 	if option_proxy_CLIPBOARD:
>> 		CLIPBOARD -> PB
>>
>> Event PB updated:
>> 	if option_proxy_pb_to_clipboard:
>> 		PB -> CLIPBOARD (this involves "grabbing" the CLIPBOARD)
>> 	if option_proxy_pb_to_primary:
>> 		PB -> PRIMARY (essentially same as above)
>>
>> Event server asks for PRIMARY/CLIPBOARD:
>> 	get what's in PB and return
>
> This won't work correctly in some cases from what I see.  The
> CLIPBOARD and PRIMARY selections are just owned.  And once owned it
> seems not all X11 apps will set ownership again (e.g. Tk and possibly
> others).  They don't technically have to.  So we have the same
> ambiguous situation as before.

We don't care if TK "resets" that it owns PRIMARY.  Primary is proxied  
on the Edit->Copy event, so the "new" value is proxied even if it  
doesn't "reassert" its claim on the second selection.

As far as CLIPBOARD goes... I think most people concerned with  
CLIPBOARD will be using GTK which doesn't exhibit this problem... but  
your "make pbproxy proxy/cache/reclaim CLIPBOARD" approach might work  
here as a solution.  But you should definitely not do that for PRIMARY  
(since it would cause selected text to always unselect).

-------------- 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/20080911/159d858b/attachment-0001.bin