[Xquartz-dev] 2.3.2_beta1

[Dave Ray]

On Oct 11, 2008, at 2:46 PM, George Peter Staplin wrote:

> Quoted Dave Ray <apple at jonive.com>:
>
>> I can copy text from Textedit -> xterm, Textedit -> Eterm
>> I can copy text from xterm -> Textedit, but NOT Eterm -> Textedit.
>> Perhaps I need to recompile that with a flag of some sort.
>
> I've never used Eterm, but if you select the text, and then do an  
> Edit->Copy in the Mac menubar it may work.

That's how I did it. I selected text in the terminal, hit command-C,  
switched to Textedit, hit command-P.

>> I can copy graphics from Preview -> Gimp, Photoshop -> Gimp and
>> Graphic Converter -> Gimp.
>>
>> I can NOT copt graphics from Gimp -> any graphics app in OS-X.
>>
>> To copy from an X11 app to OS-X, I select the text/graphic, then use
>> command-C in the OS-X menu, then I switch to the OS-X app and type
>> command-V. Let me know if I'm doing something wrong.
>
> OK, the graphical/image copying with the Gimp is different, due to  
> fundamental architectural differences.  To copy an image with the  
> Gimp go to the Gimp's Edit->Copy menu, and then you should be able  
> to paste into Preview, and other Mac apps.  There is no consistent  
> way for the Mac to trigger a copy in all X11 apps, due to the design  
> of the X11 mechanisms.

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. After this, I hit command-C.  
Then I switch to the graphics app in OS-X, and typed command-P.

>> Another observation:
>> If the selected text/graphic is selected, and then deselected, the
>> normal X11 behavior is to keep the last selected item in the X11
>> clipboard buffer, even without explicitly using keys to copy. This is
>> because X11 doesn't have global copy/paste keys like OS-X. I found
>> that if I deselect the selected item in X11, and then use command-C,
>> the item is in the X11 buffer but not copied to the OS-X clipboard.
>> This is probably by design but I wanted to be sure.
>
> Hmm.  I'm not sure I follow that.  Can you tell me step by step how  
> to reproduce that with applications?

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.  
This 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.

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. This makes sense, because  
X11's copy/paste works the X11 way and OS-X's copy/paste works the  
Apple way.

>> I thought it would be useful for you to get this kind of feedback  
>> from
>> someone not using quartz-wm.
>>
>> >> John Koren wrote
>> >>> This results in a error message " A clipboard manager is already
>> >>> running.  pbproxy will not sync clipboard to pasteboard." being
>> >>> written in the system log.
>> >>
>> >> If you are getting this message, pbproxy is still being launched
>> >> somehow, even though it is not in your .xinitrc.
>> >
>> >Or any other application that claims the CLIPBOARD_MANAGER atom
>> >(xclipboard, klipper, etc).
>>
>> So, does this mean the message "pbproxy will not sync clipboard.." is
>> a generic message that will be displayed in the startup logs if there
>> is any conflict, even if pbproxy is not installed?
>
> It basically means that the way that pbproxy works, it can clash  
> with xclipboard and the like, so it doesn't try to fight with them  
> if they are already running.

I agree but that is not the point I was trying to make. Jeremy had  
said that anybody who installed pbproxy should de-install it, because  
it is replaced by xpbproxy which is included in the new beta. These  
instructions about removing pbproxy weren't clear and I had to ask,  
and it is likely other testers still have pbproxy installed. So if  
somebody reports an error message that says something about pbproxy  
having trouble starting up, this indicates that both pbproxy and  
xpbproxy are on the same system, in error. Unless there's something  
else I'm not aware of.

Dave