Making it less ambiguous - Copy/Paste Problem
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. 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. 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 hope this is clear. George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/
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"
Quoted Jeremy Huddleston <jeremyhu@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/
Quoted George Peter Staplin <georgeps@xmission.com>:
What are your thoughts on the following?
1. get CLIPBOARD data when with have an XQuartz Edit->Copy.
That should read: get CLIPBOARD data when there is an owner of it, after 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/
On Sep 11, 2008, at 17:04, George Peter Staplin wrote:
Quoted George Peter Staplin <georgeps@xmission.com>:
What are your thoughts on the following?
1. get CLIPBOARD data when with have an XQuartz Edit->Copy.
That should read: get CLIPBOARD data when there is an owner of it, after an XQuartz Edit->Copy...
My answer is still defiantly no. Example to show why this is wrong: 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="GIMP IMAGE" There's no reason why the user should expect the result in 3a. They just selected new text and did edit->copy. Why should that proxy the gimp image just because CLIPBOARD has an owner? Additionally, CLIPBOARD will always have an owner until the window that owns it is closed... thus you'll have no way to get PRIMARY again (except for your 'do Edit->Copy a second time' approach... which breaks predictability in the HIG).
Quoted Jeremy Huddleston <jeremyhu@apple.com>:
On Sep 11, 2008, at 17:04, George Peter Staplin wrote:
Quoted George Peter Staplin <georgeps@xmission.com>:
What are your thoughts on the following?
1. get CLIPBOARD data when with have an XQuartz Edit->Copy.
That should read: get CLIPBOARD data when there is an owner of it, after an XQuartz Edit->Copy...
My answer is still defiantly no. Example to show why this is wrong:
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="GIMP IMAGE"
There's no reason why the user should expect the result in 3a. They just selected new text and did edit->copy. Why should that proxy the gimp image just because CLIPBOARD has an owner? Additionally, CLIPBOARD will always have an owner until the window that owns it is closed... thus you'll have no way to get PRIMARY again (except for your 'do Edit->Copy a second time' approach... which breaks predictability in the HIG).
Good point. You're right. George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/
On Sep 11, 2008, at 5:28 PM, Jeremy Huddleston wrote:
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="GIMP IMAGE"
That isn't, however, quite what George and I had in mind. What we had in mind would look more like this: 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" 2a) do edit->copy in gimp Proxy notices change to CLIPBOARD and copies to PRIMARY, becoming owner of PRIMARY 2b) Since we only pay attention to PRIMARY in copy-to-pasteboard operations now: PRIMARY="Owned by Proxy" 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" (since, again, we are only looking at PRIMARY). So, in essence, the CLIPBOARD becomes irrelevant to the copy-to- pasteboard operation since the proxy simply takes care to copy the CLIPBOARD to PRIMARY when an application only sets the former. It also becomes essentially impossible for an X11 app to own both CLIPBOARD and PRIMARY with different contents in each, which I consider a feature rather than a bug on our platform since that's just confusing and we're essentially forcing X11 users to face the fact that they're on a Mac. I also think it's fairly close to what you suggested a few rounds ago, so where's the flaw in that thinking? - Jordan
On Sep 11, 2008, at 18:12, Jordan K. Hubbard wrote:
That isn't, however, quite what George and I had in mind. What we had in mind would look more like this:
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" 2a) do edit->copy in gimp Proxy notices change to CLIPBOARD and copies to PRIMARY, becoming owner of PRIMARY
This just seems bizarre to me. Now you're changing PRIMARY because someone set CLIPBOARD. "Why does my xterm selection disappear when I do Edit->Copy in gimp?"
2b) Since we only pay attention to PRIMARY in copy-to-pasteboard operations now: PRIMARY="Owned by Proxy" 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" (since, again, we are only looking at PRIMARY).
So, in essence, the CLIPBOARD becomes irrelevant to the copy-to- pasteboard operation since the proxy simply takes care to copy the CLIPBOARD to PRIMARY when an application only sets the former.
This introduces a weird "PRIMARY changes when CLIPBOARD is set" problem without really addressing any specific issue in the case that I presented. George's only issue was that if an app changes what it is in it's CLIPBOARD without actually explicitly doing an XSetSelectionOwner (or whatever it is that will cause other apps to see that it has done this), then we won't "notice" the change. Your solution here does not address that particular problem (additionally, I think we should not worry about addressing that problem). 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 this is the more in-depth implementation of my original which addresses George's concern:
Event CLIPBOARD changed: if option_proxy_CLIPBOARD: CLIPBOARD -> PB
It also becomes essentially impossible for an X11 app to own both CLIPBOARD and PRIMARY with different contents in each, which I consider a feature rather than a bug on our platform since that's just confusing and we're essentially forcing X11 users to face the fact that they're on a Mac.
Well, it also causes selected text to just become unselected "for no reason" and I actually consider this a bug rather than a feature. I am of the mind that X11 should behave like X11 on its own and the pbproxy code should not introduce any behavior such as this.
I also think it's fairly close to what you suggested a few rounds ago, so where's the flaw in that thinking?
Yeah, I think at one point I did suggest that. But I no longer agree. We can address the problem without actually introducing this oddity.
On Sep 11, 2008, at 7:50 PM, Jeremy Huddleston wrote:
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
this is the more in-depth implementation of my original which addresses George's concern:
OK, that seems like a reasonable approach to me too, and without any weird PRIMARY selection side-effects. If George is convinced, we should go for it! - Jordan
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...
Well that helps...
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.
No! That breaks probably the most common use of Edit->Copy (copying selected text from xterm/nedit/etc). PRIMARY should be sent to pasteboard on the Edit->Copy event. Why would you want Edit->Copy to have anything to do with CLIPBOARD? HIG dictates that the expected behavior is that the selected item (what is in PRIMARY) is what should be sent to the PB.
2. set pbproxy as owner of CLIPBOARD. set pbproxy as owner of PRIMARY. copy the contents to NSPasteboard.
Uhm... this makes no sense to me. Why would you copy data to NSPasteboard if you're the owner of CLIPBOARD or PRIMARY? If pbproxy is the owner of PRIMARY and/or CLIPBOARD, then it means that it's "copying" from Pasteboard TO CLIPBOARD or PRIMARY. It's when someone else owns CLIPBOARD or PRIMARY that we'll be copying that to Pasteboard.
3. respond to requests from X11 for pastes of PRIMARY and possibly CLIPBOARD
Yeah, we definitely need to do that when we own PRIMARY and CLIPBOARD.
4. if Edit->Copy occurs in XQuartz and pbproxy owns CLIPBOARD, then ignore clipboard, and only copy PRIMARY to NSPasteboard.
Yeah, that's right. What are your specific complaints about the behavior/pseudocode I mentioned earlier today? That was the culmination of about 2-3 weeks of discussion on this mailing list about what expected behaviors people expected. --Jeremy
participants (3)
-
George Peter Staplin
-
Jeremy Huddleston
-
Jordan K. Hubbard