Re: [Xquartz-dev] Xquartz-dev Digest, Vol 12, Issue 7
Thanks Jeremy for explaining some of these issues. I appreciate the work that you are putting into the X11 development and I'm providing feedback in hope that it is useful in debugging. This is a very complex issue! I've retested and included details below.
On Oct 11, 2008, at 16:57, Dave Ray wrote:
That's how I did it. I selected text in the terminal, hit command-C, switched to Textedit, hit command-P.
I assume you mean command-v.
Yes, very tired, sorry..
Did you try using the menu rather than the keyboard shortcut?
Yes, tried it both ways and was the same.
I should have explained what I did a little better.. Yes this is actually what I did. I opened a JPEG image in Gimp, selected all and copied using the menus from within Gimp.
You were good up to this point. That "puts" the image into CLIPBOARD. xpbproxy then copies that to pasteboard.
After this, I hit command-C.
And this is your problem. Now, you copied whatever in PRIMARY to the pasteboard. command-c just copies what's in PRIMARY (selected). If you want what's in CLIPBOARD to be in pasteboard, that's handled automatically whenever CLIPBOARD is changed.
I may have mis-used some semantics in my previous post, with words like clipboard, buffer, etc. I've re-tested and tried to be more careful with the words I use to describe the results (below).
This is normal X11 behavior. It is just a little different that OS-X. In a terminal window, type some text and then highlight it with the mouse (button1). Then un-highlight it by clicking the mouse elsewhere in the terminal window (button 1). Then click mouse button 2, and the text you highlighted should automagically get typed into the terminal.
Right.
his is normal copy-paste behavior in the X11 world. It's natural that the question would arise, when should this buffer be allowed to get copied to the OS-X buffer. Only when it's highlighted? or, whenever it is in the X11 paste buffer. This is what I was testing and describing in my post.
We have no way to know when it's deselected. All edit->copy does is put what's in PRIMARY into pasteboard. There is nothing fancy going on behind the scenes at the X11 client level since we actually can't do anything at that level anyways.
I think that's fine - I am observing some anomalies on my system.
Under the current implementation, the text gets copied when it is highlighted, but will not copy after you click to unhighlight it, even when it remains in the X11 paste buffer.
I highly doubt that is deterministic. There's no way to actually implement the behavior you described (unless it's due to a race condition)... and I just tested it out here and it works as expected.
Well I just re-tested and I really am seeing this. Here's a more expanded description of what I'm seeing with copy/paste, which I've taken the time to capture in hope that it is helpful for developers. If I type text at the prompt in xterm, highlight it with the mouse, then deselect it, then select OS-X menu Edit-> Copy (also tried command-C) then try to paste in Textedit and nothing happens, but in xterm I can still recall that previously highlighted text with button 2, as expected for X11. If I do the exact same thing, but select OS-X Edit-> Copy while the text in xterm is still highlighted, it does copy to Textedit. I get the same result with command-C as I do with Edit -> Copy. I am seeing an anomaly between Eterm and xterm that I have never seen on an X11 system. First I cannot copy text to Textedit with Eterm at all, even using the way that works from xterm. If I do the copy/paste routine I described in an Eterm, I can button-2 the previously selected text in the same Eterm window, and across to another xterm window. But if I highlight the text in Eterm and use OS-X menu Edit -> Copy, I get a system beep (as though it had nothing to copy) and nothing pastes in Textedit. Now, if I do the same copy/paste routine in xterm, I can button-2 the previously selected text in the same xterm window and Textedit but NOT into Eterm. Weird.... The thing that won't copy into Eterm is the only thing that will copy into Textedit.. a coincidence? Is there something wrong with my Eterm, or is this the symptom of something going on system wide in X11? On the graphics side, I re-tested and have some details. I can copy from Preview to Gimp, but not vise-versa. I tried every possible way I could think of that might work. After opening and selecting an image in Gimp, I tried just selecting an area and then using OS-X Copy; tried selecting an area, using Edit -> Copy from within Gimp, then using OS-X copy. Tried all these with command-C in place of the OS-X menu copy. None of these combinations would paste into Preview or Photoshop from Gimp. I cannot copy from Adobe Photoshop Elements 6.0 to Gimp at all. This is strange: When I copy an image in Photoshop, I can paste it into Preview, but not X11 Gimp. When I copy an image in Preview, I can paste it into both Photoshop and into X11 Gimp. Let me know if these details are useful. Dave
Did you try using the menu rather than the keyboard shortcut?
Yes, tried it both ways and was the same.
Well I can't reproduce that at all... I'll get you a binary with debug spew to try out (or maybe George can get it for you)
I highly doubt that is deterministic. There's no way to actually implement the behavior you described (unless it's due to a race condition)... and I just tested it out here and it works as expected.
Well I just re-tested and I really am seeing this. Here's a more expanded description of what I'm seeing with copy/paste, which I've taken the time to capture in hope that it is helpful for developers.
If I type text at the prompt in xterm, highlight it with the mouse, then deselect it, then select OS-X menu Edit-> Copy (also tried command-C) then try to paste in Textedit and nothing happens, but in xterm I can still recall that previously highlighted text with button 2, as expected for X11. If I do the exact same thing, but select OS-X Edit-> Copy while the text in xterm is still highlighted, it does copy to Textedit. I get the same result with command-C as I do with Edit -> Copy.
Hmm... actually, I was just testing with urxvt. I see the behavior you describe when using xterm, and I can only surmise that it responds differently when it is unselected than when it's selected. I'll leave this in George's court, but it's definitely specific to xterm (and I guess your eterm as well). urxvt works as expected.
Is there something wrong with my Eterm, or is this the symptom of something going on system wide in X11?
It's probably something specific to eterm and xterm. We have issues with nedit too...
On the graphics side, I re-tested and have some details. I can copy from Preview to Gimp, but not vise-versa. I tried every possible way I could think of that might work. After opening and selecting an image in Gimp, I tried just selecting an area and then using OS-X Copy; tried selecting an area, using Edit -> Copy from within Gimp, then using OS-X copy. Tried all these with command-C in place of the OS-X menu copy. None of these combinations would paste into Preview or Photoshop from Gimp.
I cannot copy from Adobe Photoshop Elements 6.0 to Gimp at all. This is strange: When I copy an image in Photoshop, I can paste it into Preview, but not X11 Gimp. When I copy an image in Preview, I can paste it into both Photoshop and into X11 Gimp.
We'll have to see what the debug output shows... --Jeremy
Quoted Jeremy Huddleston <jeremyhu@apple.com>:
Did you try using the menu rather than the keyboard shortcut?
Yes, tried it both ways and was the same.
Well I can't reproduce that at all... I'll get you a binary with debug spew to try out (or maybe George can get it for you)
I highly doubt that is deterministic. There's no way to actually implement the behavior you described (unless it's due to a race condition)... and I just tested it out here and it works as expected.
Well I just re-tested and I really am seeing this. Here's a more expanded description of what I'm seeing with copy/paste, which I've taken the time to capture in hope that it is helpful for developers.
If I type text at the prompt in xterm, highlight it with the mouse, then deselect it, then select OS-X menu Edit-> Copy (also tried command-C) then try to paste in Textedit and nothing happens, but in xterm I can still recall that previously highlighted text with button 2, as expected for X11. If I do the exact same thing, but select OS-X Edit-> Copy while the text in xterm is still highlighted, it does copy to Textedit. I get the same result with command-C as I do with Edit -> Copy.
Hmm... actually, I was just testing with urxvt. I see the behavior you describe when using xterm, and I can only surmise that it responds differently when it is unselected than when it's selected. I'll leave this in George's court, but it's definitely specific to xterm (and I guess your eterm as well).
It's a feature of xterm. I'm not sure why they have it work that way in xterm. Thomas Dickey may know why. The way it works is that when text is selected then PRIMARY is owned (unless you use the selectToClipboard resource), and when no text is selected the owner is set to None. When you are actually pasting with button 2 it's pulling from the CUT_BUFFER0 when the PRIMARY isn't owned. I don't understand enough about CUT_BUFFERS, and why there are 8 of them. I think they aren't even in the ICCCM. My understanding is that they are an old method of client selection communication, that only a few old apps use.
urxvt works as expected.
Is there something wrong with my Eterm, or is this the symptom of something going on system wide in X11?
It's probably something specific to eterm and xterm. We have issues with nedit too...
I'm not sure why eterm is behaving that way. I will try to see why soon.
On the graphics side, I re-tested and have some details. I can copy from Preview to Gimp, but not vise-versa. I tried every possible way I could think of that might work. After opening and selecting an image in Gimp, I tried just selecting an area and then using OS-X Copy; tried selecting an area, using Edit -> Copy from within Gimp, then using OS-X copy. Tried all these with command-C in place of the OS-X menu copy. None of these combinations would paste into Preview or Photoshop from Gimp.
I cannot copy from Adobe Photoshop Elements 6.0 to Gimp at all. This is strange: When I copy an image in Photoshop, I can paste it into Preview, but not X11 Gimp. When I copy an image in Preview, I can paste it into both Photoshop and into X11 Gimp.
I think it will work, given the details that were provided in another message I responded to. Just let the Gimp Edit->Copy menu do the act of copying the data, and then go Paste in your Mac Photoshop. It should work just fine, though I don't have photoshop to test with, it works for me from the Gimp to Preview. George -- http://people.freedesktop.org/~gstaplin/
On Oct 11, 2008, at 9:42 PM, Dave Ray wrote:
On the graphics side, I re-tested and have some details. I can copy from Preview to Gimp, but not vise-versa. I tried every possible way I could think of that might work. After opening and selecting an image in Gimp, I tried just selecting an area and then using OS-X Copy; tried selecting an area, using Edit -> Copy from within Gimp, then using OS-X copy. Tried all these with command-C in place of the OS-X menu copy. None of these combinations would paste into Preview or Photoshop from Gimp.
No no no. You're still doing it wrong. :-) With an application like Gimp that has its own Copy menu item (in the menu bar in the Gimp window), you don't use OS X's Copy at all. So you should just hit ctrl- C (aka Gimp's Copy) and then switch to Preview or whatever and paste. You only use OS X's Copy (command-C) for applications that don't have their own Copy menu item, like xterm. This difference exists because there are two different mechanisms for supporting copy and paste in X11, which is why Jeremy keeps talking about CLIPBOARD vs. PRIMARY.
Quoted William Mortensen <william5@u.washington.edu>:
On Oct 11, 2008, at 9:42 PM, Dave Ray wrote:
On the graphics side, I re-tested and have some details. I can copy from Preview to Gimp, but not vise-versa. I tried every possible way I could think of that might work. After opening and selecting an image in Gimp, I tried just selecting an area and then using OS-X Copy; tried selecting an area, using Edit -> Copy from within Gimp, then using OS-X copy. Tried all these with command-C in place of the OS-X menu copy. None of these combinations would paste into Preview or Photoshop from Gimp.
No no no. You're still doing it wrong. :-) With an application like Gimp that has its own Copy menu item (in the menu bar in the Gimp window), you don't use OS X's Copy at all. So you should just hit ctrl- C (aka Gimp's Copy) and then switch to Preview or whatever and paste.
That's correct. I usually use the Gimp Edit->Copy menu, and then the Mac Preview Edit->Paste. We tried to make it more sensible than my original idea of having Copy Primary, and Copy Clipboard menu items. It does a greedy (automatic) copy of the CLIPBOARD selection whenever the CLIPBOARD selection is lost from another client owning it. This is just like a standard X11 clipboard manager, hence the inability to fight with xclipboard and similar programs, which do similar things. You can however disable the pasteboard proxying in the X11 preferences of CLIPBOARD if you want.
You only use OS X's Copy (command-C) for applications that don't have their own Copy menu item, like xterm. This difference exists because there are two different mechanisms for supporting copy and paste in X11, which is why Jeremy keeps talking about CLIPBOARD vs. PRIMARY.
That's a very clear way of putting it -- thank you :) The inverse of copying from say the Gimp to Preview works like this: When you copy text or an image from a Mac app the proxy will set itself as owner of the X11 PRIMARY and CLIPBOARD (depending on if you're using the standard XQuartz preferences), which thereby allows pasting into an X11 app with a middle-button, key shortcut, or menu. George -- http://people.freedesktop.org/~gstaplin/
participants (4)
-
Dave Ray
-
George Peter Staplin
-
Jeremy Huddleston
-
William Mortensen