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

[George Peter Staplin]

Quoted Jeremy Huddleston <jeremyhu at apple.com>:
> 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.

Hehe, I'm a Tcl and Tk core developer/maintainer at SourceForge...


>> 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"


Jordan Hubbard and I talked some more about ideas to solve this.

What are your thoughts on the following?

  1. get CLIPBOARD data when with have an XQuartz Edit->Copy.
  2. set pbproxy as owner of CLIPBOARD.  set pbproxy as owner of  
PRIMARY.   copy the contents to NSPasteboard.
  3. respond to requests from X11 for pastes of PRIMARY and possibly CLIPBOARD
  4. if Edit->Copy occurs in XQuartz and pbproxy owns CLIPBOARD, then  
ignore clipboard, and only copy PRIMARY to NSPasteboard.

I think that works.  It's complex stuff though, so if you see a  
problem with that approach please let me know.

George
-- 
http://www.xmission.com/~georgeps/  http://whim.linuxsys.net
http://code.google.com/p/megapkg/