Re: Clipboard periodically breaks
On Thu Sep 26 20:35:21 2013, Matt D. wrote: However, an environment variable that tells it which clipboard to use would provide an immediate solution and be used used on a per-application basis. For example, I can use aliases when launching programs: $ xclip=clipboard1 gedit $@ (monitor only clipboard 1) $ xclip=clipboard2 gedit $@ (monitor only clipboard 2) No option would indicate that both clipboard 1 and clipboard 2 would be handled as they are now. I'm not familiar with X programming but I'm assuming here that it would be possible for xclip to read from a particular process's own environment (rather than xclip's own) while processing a clipboard event to do this. What do you think? This is not straightforward to implement and is not really a good solution as it won't work for remote X clients. In theory, it might be possible to annotate the X client window with a property which tells XWin/xwinclip how to treat it's clipboard use, but since the clipboard-owning window is often a hidden one, getting that property on there poses problems. Hopefully the -noprimary option makes this less of an issue. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Clipboard periodically breaks
On Thu Sep 26 20:35:21 2013, m...@codespunk.com (Matt D.) wrote: Jon, Thanks for looking into this. I can confirm that your changes correct the issue where highlighting next would cause arbitrary pastes to occur. Good work! I also concede that there does not seem to be a good solution to transparently fix the two-to-one clipboard issue; as XWin may indeed be able to interpret calls to X's two clipboards, there wouldn't be any reasonable way for it to identify which clipboard is actually being used. I'm reading this wich much interest: for me, too, copy-pasting between Windows applications and Cygwin xterms to break after some time, and this has been happening for a year or so. I'm not aware of doing anything special to cause it to break, but the only way I know how to fix it is to restart X. This is with recent Cygwin packages on Windows 7. I haven't tested with a newer build of the X server. However, an environment variable that tells it which clipboard to use would provide an immediate solution and be used used on a per-application basis. For example, I can use aliases when launching programs: $ xclip=clipboard1 gedit $@ (monitor only clipboard 1) $ xclip=clipboard2 gedit $@ (monitor only clipboard 2) No option would indicate that both clipboard 1 and clipboard 2 would be handled as they are now. I'm not familiar with X programming but I'm assuming here that it would be possible for xclip to read from a particular process's own environment (rather than xclip's own) while processing a clipboard event to do this. What do you think? As an interested bystander, I have no doubt that that type of specific solution to specific clipboard interaction problems can possibly work, but using them will require detailed knowledge of how the X and Windows clipboards interact. My question is different: is it possible to implement the interaction in such a way that a user such as me, who is not aware of any subtleties, can get consistency, in the sense that all copy-paste actions between X an Windows that work when X is started continue to work in the same way for the duration of the session? Matt D. -- Reinier Post TU Eindhoven -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Clipboard periodically breaks
Jon, Thanks for looking into this. I can confirm that your changes correct the issue where highlighting next would cause arbitrary pastes to occur. Good work! I also concede that there does not seem to be a good solution to transparently fix the two-to-one clipboard issue; as XWin may indeed be able to interpret calls to X's two clipboards, there wouldn't be any reasonable way for it to identify which clipboard is actually being used. However, an environment variable that tells it which clipboard to use would provide an immediate solution and be used used on a per-application basis. For example, I can use aliases when launching programs: $ xclip=clipboard1 gedit $@ (monitor only clipboard 1) $ xclip=clipboard2 gedit $@ (monitor only clipboard 2) No option would indicate that both clipboard 1 and clipboard 2 would be handled as they are now. I'm not familiar with X programming but I'm assuming here that it would be possible for xclip to read from a particular process's own environment (rather than xclip's own) while processing a clipboard event to do this. What do you think? Matt D. On 9/26/2013 11:37 AM, Jon TURNEY wrote: In-Reply-To: 51c44820.4010...@dronecode.org.uk Please start a new thread for a new subject. On 22/09/2013 03:38, Matt D. wrote: I often keep gedit sessions open on remote servers for maintaining various scripts. The problem I've encountered is that after a while I can no longer copy/paste between X and Windows. For example, I'll copy in windows and attempt to paste in gedit but nothing will happen. However, if I then proceed to copy something in gedit it will immediate paste that in place of where I had previously tried to paste from Windows. Sometimes I can get it working again by bombarding the clipboard with copy/pastes from both X and Windows. But most of the time I have to exit the ssh session and reconnect. Is this a known problem? We know there are bugs, but we don't know what they all are :-) Here is an example screen capture and repeatable bug of the clipboard breaking. Synopsis: Copy from Windows, highlight text in gedit, clipboard breaks (paste doesn't work). Proceed to copy from gedit and suddenly that text gets pasted. Sometimes it will just start pasting while a selection is being made.. ?? Download the video here in Xvid format: http://codespunk.com/files/upload/cygwinx_clipboard_breaking_xvid.avi Thanks for this. There's definitely a bug here when stuff fails to paste. You are also having difficulties because of a limitation of the current clipboard implementation I'll try to explain: As [1] tries to explain, there are 2 X selections of interest, the PRIMARY selection (the highlighted text) and the CLIPBOARD selection (the cut/copied text) (and some X applications only use one or the other), but only 1 windows clipboard. When you update the PRIMARY selection, by highlighting that text, it is made available for pasting from the Windows clipboard, which means that the previous Windows clipboard contents are removed. When you then go to paste, since the Windows clipboard contents have changed to the selected text, that's what you get in the CLIPBOARD selection. This is far from idea, but the proposed solutions I've seen so far aren't any better: i) Don't monitor the PRIMARY selection. This breaks with any application which only uses the PRIMARY selection (e.g. xterm, emacs in default configurations) ii) Use some more complex heuristic than 'most recently changed owner' for choosing which selection to make available in the Windows clipboard. It's very hard to know if this will make things better on average. I've fixed something else that might be related to the paste failure, so please try the latest snapshot [2],[3]. If you can still reproduce your problem with that, can you please try: * run XWin with the -noclipboard flag added to your usual flags. * Then run xwinclip, which should produce some useful logs when you reproduce your problem. [1] http://x.cygwin.com/docs/ug/using-clipboard-integration.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20130924-git-d5a9aea0e48a088b.exe.bz2 [3] ftp://cygwin.com/pub/cygwinx/xwinclip.20130924-git-d5a9aea0e48a088b.exe.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Clipboard periodically breaks
I often keep gedit sessions open on remote servers for maintaining various scripts. The problem I've encountered is that after a while I can no longer copy/paste between X and Windows. For example, I'll copy in windows and attempt to paste in gedit but nothing will happen. However, if I then proceed to copy something in gedit it will immediate paste that in place of where I had previously tried to paste from Windows. Sometimes I can get it working again by bombarding the clipboard with copy/pastes from both X and Windows. But most of the time I have to exit the ssh session and reconnect. Is this a known problem? I am using the Cygwin x32 with the latest packages. Matt D. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Clipboard periodically breaks
Here is an example screen capture and repeatable bug of the clipboard breaking. Synopsis: Copy from Windows, highlight text in gedit, clipboard breaks (paste doesn't work). Proceed to copy from gedit and suddenly that text gets pasted. Sometimes it will just start pasting while a selection is being made.. ?? Download the video here in Xvid format: http://codespunk.com/files/upload/cygwinx_clipboard_breaking_xvid.avi Matt D. On 9/21/2013 10:38 PM, Matt D. wrote: I often keep gedit sessions open on remote servers for maintaining various scripts. The problem I've encountered is that after a while I can no longer copy/paste between X and Windows. For example, I'll copy in windows and attempt to paste in gedit but nothing will happen. However, if I then proceed to copy something in gedit it will immediate paste that in place of where I had previously tried to paste from Windows. Sometimes I can get it working again by bombarding the clipboard with copy/pastes from both X and Windows. But most of the time I have to exit the ssh session and reconnect. Is this a known problem? I am using the Cygwin x32 with the latest packages. Matt D. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
