[Xquartz-dev] Making it less ambiguous - Copy/Paste Problem

[Jeremy Huddleston]

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

> Hi,
>
> This code I just wrote demonstrates part of the idea:
> http://www.xmission.com/~georgeps/xfixes_clipboard.c
>
> We can use something like that to determine which window most recently
> set ownership of the selection, and what selection was involved.
>
> However there is still an unfortunate ambiguity still.  The X11 Tk
> text widget doesn't set the PRIMARY or CLIPBOARD again if it already
> has acquired it.

Well we don't really have a way to address this on the server level  
short of polling or updating when X11 looses focus.  I don't like  
either of those ideas.  Plus Tk is old, cruddy, and broken in this  
regard.  I would work on assuming things do it "the GTK way" and maybe  
work on getting a patch made for TK.

> Gtk+ apps always request ownership again, even if they already own it.
>
> The ambiguity is this:
> 1. select some text to own PRIMARY in an X11 Tk text widget.
> 2. do an Edit->Copy to get a Gimp image into the CLIPBOARD.
> 3. select some text in a Tk text widget that already owned PRIMARY.
> Nothing happens, so the code will think the last selection was from
> the Gimp.

Uhm.  Well... yeah.  That's just how it's gonna have to be.  Plus,  
this isn't really *THAT* big of a deal... because our Edit->Copy (in  
X11.app's menu) will force the current PRIMARY to be sent to  
PASTEBOARD... so really the only problem lies in the 'proxy to  
pasteboard on select' option which will be disabled by default.

So yeah... just ignore this problem for now because (a) it isn't going  
to be a problem in the default configuration and (b) it only exists in  
old crufty toolkits and (c) we can probably patch those toolkits to  
fix this issue down the road.

> Unfortunately we can't copy images from most Gtk+ apps unless we
> support CLIPBOARD, and if this ambiguous situation continues to
> persist, there is little hope for the default Copy/Paste menus to work
> properly in all cases.

I fail to see how this ambiguity is a blocker.  Assuming default  
options:
option_proxy_on_select=FALSE
option_proxy_clipboard=TRUE
option_proxy_pb_to_clipboard=TRUE
option_proxy_pb_to_primary=TRUE

we have:

1) select text in the TK Widget
PRIMARY="Owned by TK" CLIPBOARD=NULL PASTEBOARD=NULL
1a) Do X11.app's Edit->Copy
PRIMARY="Owned by TK" CLIPBOARD=NULL PASTEBOARD="TK Text 1"
2) do edit->copy in gimp
PRIMARY="Owned by TK" CLIPBOARD="Owned by Gimp" PASTEBOARD="GIMP IMAGE"
3) select new text in TK Widget
PRIMARY="Owned by TK" CLIPBOARD="Owned by Gimp" PASTEBOARD="GIMP IMAGE"
3a) Do X11.app's Edit->Copy
PRIMARY="Owned by TK" CLIPBOARD="Owned by Gimp" PASTEBOARD="TK Text 2"



-------------- 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/81e45701/attachment.bin