Re: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
Hi, Bugzilla 5735 raised https://bugs.freedesktop.org/show_bug.cgi?id=5735 which includes the patch. Colin Harrison -- 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: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
Hi,
Stahlman Brett wrote:
I will try to look into
it as I get time over the next few days...
I can quickly build an experimental Xming.exe with any patch you have in
mind.
(Xming shares the same code base as Cygwin/X).
If proven the patch could then be incorporated into Cygwin/X, at leisure,
via an XOrg bugzilla.
Colin Harrison
Colin,
Here's an experimental patch. It appears to fix the issue I was
having with unix gvim running on Windows. Hopefully, it doesn't break
anything else. I was able to keep all of the changes in a single file:
winclipboardwndproc.c. Included is a unified context diff, performed
from the ...hw/xwin directory. Let me know if you have any problems
with the format and would like me to send as attachment or in a
different format.
Also, let me know if you aren't sure how to reproduce the problem the
patch is supposed to fix. Basically, any X app that doesn't implement a
workaround (and some probably do) would exhibit the buggy clipboard
behavior with the unpatched X server... For details on the problem,
you can visit the thread
Patch for problems with X11 GUI / XTERM clipboard integration with
native Win applications - was clipboard support
on the [EMAIL PROTECTED] mailing list.
Thanks in advance,
Brett Stahlman
*** winclipboardwndproc.c Wed Jan 25 06:42:50 2006
--- winclipboardwndproc_bps.c Wed Jan 25 06:50:21 2006
***
*** 49,54
--- 49,56
extern Window g_iClipboardWindow;
extern Atom g_atomLastOwnedSelection;
+ /* BPS - g_hwndClipboard needed for X app-Windows paste fix */
+ extern HWND g_hwndClipboard;
/*
* Local function prototypes
***
*** 134,139
--- 136,147
* Process a given Windows message
*/
+ /* BPS - Define our own message, which we'll post to ourselves to facilitate
+ * resetting the delayed rendering mechanism after each paste from X app to
+ * Windows app. TODO - Perhaps move to win.h with the other WM_USER messages.
+ */
+ #define WM_USER_PASTE_COMPLETE (WM_USER + 1003)
+
LRESULT CALLBACK
winClipboardWindowProc (HWND hwnd, UINT message,
WPARAM wParam, LPARAM lParam)
***
*** 527,532
--- 535,547
SetClipboardData (CF_TEXT, NULL);
}
+ /* BPS - Post ourselves a user message whose handler will reset the
+ * delayed rendering mechanism after the paste is complete. This is
+ * necessary because calling SetClipboardData() with a NULL argument
+ * here will cause the data we just put on the clipboard to be lost!
+ */
+ PostMessage(g_hwndClipboard, WM_USER_PASTE_COMPLETE, 0, 0);
+
/* Special handling for WM_RENDERALLFORMATS */
if (message == WM_RENDERALLFORMATS)
{
***
*** 544,549
--- 559,609
winDebug (winClipboardWindowProc - WM_RENDER*FORMAT - Returning.\n);
return 0;
}
+ /* BPS - This WM_USER message is posted by us. It gives us the opportunity
+ * to reset the delayed rendering mechanism after each and every paste
+ * from an X app to a Windows app. Without such a mechanism, subsequent
+ * changes of selection in the X app owning the selection are not
+ * reflected in pastes into Windows apps, since Windows won't send us the
+ * WM_RENDERFORMAT message unless someone has set changed data (or NULL)
+ * on the clipboard. */
+ case WM_USER_PASTE_COMPLETE:
+ {
+ if (hwnd != GetClipboardOwner ())
+/* In case we've lost the selection since posting the message */
+return 0;
+ winDebug (winClipboardWindowProc - WM_USER_PASTE_COMPLETE\n);
+
+ /* Set up for another delayed rendering callback */
+ if (!OpenClipboard (g_hwndClipboard))
+{
+ ErrorF (winClipboardWindowProc - OpenClipboard () failed: %08x\n,
+ (int) GetLastError ());
+}
+
+ /* Take ownership of the Windows clipboard */
+ if (!EmptyClipboard ())
+{
+ ErrorF (winClipboardWindowProc - EmptyClipboard () failed: %08x\n,
+ (int) GetLastError ());
+}
+
+ /* Advertise Unicode if we support it */
+ if (g_fUnicodeSupport)
+SetClipboardData (CF_UNICODETEXT, NULL);
+
+ /* Always advertise regular text */
+ SetClipboardData (CF_TEXT, NULL);
+
+ /* Release the clipboard */
+ if (!CloseClipboard ())
+{
+ ErrorF (winClipboardWindowProc - CloseClipboard () failed:
+ %08x\n,
+ (int) GetLastError ());
+}
+
+ }
+ return 0;
}
/* Let Windows perform default processing for unhandled messages */
--
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: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
Hi, Stahlman Brett wrote: Here's an experimental patch. Did a quick build and it works for me. I'll do some more testing and tracing, just to be sure. I had 'fun' with the patch from the mailing list, so need a cross check, to test for typos etc. Then I'll raise a bugzilla on Xorg, and also post an experimental Xming for general testing. I don't build Cygwin/X so can't do the same with a .exe here. Thanks Colin Harrison -- 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: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
Hi, Stahlman Brett wrote: I will try to look into it as I get time over the next few days... I can quickly build an experimental Xming.exe with any patch you have in mind. (Xming shares the same code base as Cygwin/X). If proven the patch could then be incorporated into Cygwin/X, at leisure, via an XOrg bugzilla. Colin, I have managed to build XWin.exe with a first-cut of my proposed solution. It appears to work. At least, a paste in a Windows app gets the latest selection from the unpatched version of gvim. There is something I need to look into however. This may just be the way gvim works, but I've noticed that the PRIMARY selection always takes precedence over CLIPBOARD, even when there's no longer anything visually selected in gvim and there's been a yank to the '+' register since text was deselected. My feeling is that this must be just the way vim works, since I know that X is calling Vim's callback for each subsequent paste into a Windows app, but I need to dig through Vim's source code a bit to understand why it happens this way. In case I didn't make the situation clear, basically, it's like this: after opening gvim, you can make selections into the '+' register and paste into a Windows app, and everything works fine, even for multiple copies and pastes. However, once you've either selected something into the '*' register (PRIMARY), or selected text with the mouse in gvim, subsequent pastes into a Windows app will always reflect what's in the '*' register, even if you go back to gvim and deselect text and yank into the '+' register. It continues like this until another app has owned the selection. Note that vim does copy text yanked to '+' into '*', so perhaps text is always being pasted from PRIMARY. As I said, I need some time to go through the Vim source here and figure out exactly what's happening. I'll keep you posted... Thanks, Brett S. Colin Harrison -- 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: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
Hi, Stahlman Brett wrote: I will try to look into it as I get time over the next few days... I can quickly build an experimental Xming.exe with any patch you have in mind. (Xming shares the same code base as Cygwin/X). If proven the patch could then be incorporated into Cygwin/X, at leisure, via an XOrg bugzilla. Colin Harrison -- 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: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
Hi, Stahlman Brett wrote: I will try to look into it as I get time over the next few days... I can quickly build an experimental Xming.exe with any patch you have in mind. (Xming shares the same code base as Cygwin/X). If proven the patch could then be incorporated into Cygwin/X, at leisure, via an XOrg bugzilla. Colin, Thanks. That may prove to be the best route. I'm actually in the process of attempting to build XWin now, but if I run into problems that look as though they could take a while to get resolved, I will plan to send you a patch. If it works as I expect, the change will be limited to a single file - a single statement, in fact. Thanks again, Brett Stahlman Colin Harrison -- 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/
Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
Recently, I built a Cygwin X-enabled Vim from the Unix sources on my Windows machine. Everything seemed to work well until I attempted to use the clipboard. The first attempt worked, but subsequent attempts to copy text in Vim and paste to a native Windows application failed. (The original text was pasted each time.) I looked into the issue, and actually wrote a patch for Unix Vim that allows me to use the clipboard normally for pasting to native Win applications. However, Bram Moolenaar of Vim insists (and I have come to agree) that the problem is not with Vim but with the Cygwin X implementation. Here's the problem as I understand it... When an X app such as Vim wants to obtain selection ownership, it calls a function such as XtOwnSelection (or the analogous toolkit-specific wrapper). Cygwin X processes this request by opening the Windows clipboard and calling SetClipboardData with a NULL data pointer, signifying that Windows should send a WM_RENDERFORMAT message when selection data is required for pasting into a native Windows application. This works fine for the first selection. The problem occurs when the user of the X app returns to the X app and changes the selection. In general, the X app will not make another call to XtOwnSelection (or the analogous function) because it already owns the selection and assumes it will communicate the changed data to X only when its callback function is called; i.e., when the selection is requested by another app. Unfortunately, the callback will not be called upon subsequent paste attempts for the following reason: Windows sends the WM_RENDERFORMAT message to Cygwin X's xwinclip window if and only if it believes the data it received in response to the last WM_RENDERFORMAT message is no longer valid. From Windows' standpoint, if there have been no intervening calls to OpenClipboard / SetClipboardData, the clipboard is unchanged, and there's no reason to send another WM_RENDERFORMAT message to the clipboard owner (xwinclip)! Thus, once a given X app owns the selection, subsequent paste operations into a native Windows application will always result in a paste of the initial selection made in the X app! The data pasted into Windows apps will not change until the selection owner changes. The patch I implemented for Vim worked by forcing a change of selection owner every time the selection within Vim changed. The solution was a bit messy, as it required ignoring the lose selection callback, and in the case of GTK, required processing X events between the call to disown and own selection. Also, this solution is inefficient, as multiple messages (e.g., WM_DESTROYCLIPBOARD, WM_DRAWCLIPBOARD) result from every change of selection, and the selection may change rapidly when, for example, you're selecting text with the mouse. Bram's other argument against expecting X applications to implement workarounds such as this is that it's not supposed to be necessary. There is no requirement that an X app make a call into X every time the selection changes. His suggestion (if I understood it correctly), which I believe is very feasible, is to have XWin re-call SetClipboardData with a NULL data pointer after processing each and every WM_RENDERFORMAT message. This would effectively invalidate the data in the clipboard after each time it was requested, forcing Windows to request it from xwinclip every time the user of a Windows app performs a paste. Is there any reason why this solution is not feasible? Have I misunderstood something about the nature of the problem? Thanks, Brett Stahlman .. Mit freundlichem Gruß / Kind regards Brett Stahlman Senior Software Engineer Siemens VDO Automotive AG SV C BC 100 Electronics Blvd #240001 Huntsville, AL 35824-6401 The United States of America Tel. 001.256.464.2227 Fax 001.256.464.2786 E-Mail: [EMAIL PROTECTED] Internet: http://www.siemensvdo.com -- 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: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
On Wed, 18 Jan 2006, Stahlman Brett wrote: Recently, I built a Cygwin X-enabled Vim from the Unix sources on my Windows machine. Everything seemed to work well until I attempted to use the clipboard. The first attempt worked, but subsequent attempts to copy text in Vim and paste to a native Windows application failed. (The original text was pasted each time.) I looked into the issue, and actually wrote a patch for Unix Vim that allows me to use the clipboard normally for pasting to native Win applications. However, Bram Moolenaar of Vim insists (and I have come to agree) that the problem is not with Vim but with the Cygwin X implementation. Here's the problem as I understand it... When an X app such as Vim wants to obtain selection ownership, it calls a function such as XtOwnSelection (or the analogous toolkit-specific wrapper). Cygwin X processes this request by opening the Windows clipboard and calling SetClipboardData with a NULL data pointer, signifying that Windows should send a WM_RENDERFORMAT message when selection data is required for pasting into a native Windows application. This works fine for the first selection. The problem occurs when the user of the X app returns to the X app and changes the selection. In general, the X app will not make another call to XtOwnSelection (or the analogous function) because it already owns the selection and assumes it will communicate the changed data to X only when its callback function is called; i.e., when the selection is requested by another app. Unfortunately, the callback will not be called upon subsequent paste attempts for the following reason: Windows sends the WM_RENDERFORMAT message to Cygwin X's xwinclip window if and only if it believes the data it received in response to the last WM_RENDERFORMAT message is no longer valid. From Windows' standpoint, if there have been no intervening calls to OpenClipboard / SetClipboardData, the clipboard is unchanged, and there's no reason to send another WM_RENDERFORMAT message to the clipboard owner (xwinclip)! Thus, once a given X app owns the selection, subsequent paste operations into a native Windows application will always result in a paste of the initial selection made in the X app! The data pasted into Windows apps will not change until the selection owner changes. The patch I implemented for Vim worked by forcing a change of selection owner every time the selection within Vim changed. The solution was a bit messy, as it required ignoring the lose selection callback, and in the case of GTK, required processing X events between the call to disown and own selection. Also, this solution is inefficient, as multiple messages (e.g., WM_DESTROYCLIPBOARD, WM_DRAWCLIPBOARD) result from every change of selection, and the selection may change rapidly when, for example, you're selecting text with the mouse. Bram's other argument against expecting X applications to implement workarounds such as this is that it's not supposed to be necessary. There is no requirement that an X app make a call into X every time the selection changes. His suggestion (if I understood it correctly), which I believe is very feasible, is to have XWin re-call SetClipboardData with a NULL data pointer after processing each and every WM_RENDERFORMAT message. This would effectively invalidate the data in the clipboard after each time it was requested, forcing Windows to request it from xwinclip every time the user of a Windows app performs a paste. Is there any reason why this solution is not feasible? Have I misunderstood something about the nature of the problem? I'm not very familiar with the details of how the clipboard handling is implemented in Cygwin/X (though I do know that there is a choice of the external xwinclip application and the internal -clipboard handling). The way applications like Exceed seem to do it is by relinquishing clipboard ownership on losing focus, and reacquiring the clipboard on getting the focus. Perhaps this approach will also work for Cygwin/X? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
Recently, I built a Cygwin X-enabled Vim from the Unix sources on my Windows machine. Everything seemed to work well until I attempted to use the clipboard. The first attempt worked, but subsequent attempts to copy text in Vim and paste to a native Windows application failed. (The original text was pasted each time.) I looked into the issue, and actually wrote a patch for Unix Vim that allows me to use the clipboard normally for pasting to native Win applications. However, Bram Moolenaar of Vim insists (and I have come to agree) that the problem is not with Vim but with the Cygwin X implementation. Here's the problem as I understand it... When an X app such as Vim wants to obtain selection ownership, it calls a function such as XtOwnSelection (or the analogous toolkit-specific wrapper). Cygwin X processes this request by opening the Windows clipboard and calling SetClipboardData with a NULL data pointer, signifying that Windows should send a WM_RENDERFORMAT message when selection data is required for pasting into a native Windows application. This works fine for the first selection. The problem occurs when the user of the X app returns to the X app and changes the selection. In general, the X app will not make another call to XtOwnSelection (or the analogous function) because it already owns the selection and assumes it will communicate the changed data to X only when its callback function is called; i.e., when the selection is requested by another app. Unfortunately, the callback will not be called upon subsequent paste attempts for the following reason: Windows sends the WM_RENDERFORMAT message to Cygwin X's xwinclip window if and only if it believes the data it received in response to the last WM_RENDERFORMAT message is no longer valid. From Windows' standpoint, if there have been no intervening calls to OpenClipboard / SetClipboardData, the clipboard is unchanged, and there's no reason to send another WM_RENDERFORMAT message to the clipboard owner (xwinclip)! Thus, once a given X app owns the selection, subsequent paste operations into a native Windows application will always result in a paste of the initial selection made in the X app! The data pasted into Windows apps will not change until the selection owner changes. The patch I implemented for Vim worked by forcing a change of selection owner every time the selection within Vim changed. The solution was a bit messy, as it required ignoring the lose selection callback, and in the case of GTK, required processing X events between the call to disown and own selection. Also, this solution is inefficient, as multiple messages (e.g., WM_DESTROYCLIPBOARD, WM_DRAWCLIPBOARD) result from every change of selection, and the selection may change rapidly when, for example, you're selecting text with the mouse. Bram's other argument against expecting X applications to implement workarounds such as this is that it's not supposed to be necessary. There is no requirement that an X app make a call into X every time the selection changes. His suggestion (if I understood it correctly), which I believe is very feasible, is to have XWin re-call SetClipboardData with a NULL data pointer after processing each and every WM_RENDERFORMAT message. This would effectively invalidate the data in the clipboard after each time it was requested, forcing Windows to request it from xwinclip every time the user of a Windows app performs a paste. Is there any reason why this solution is not feasible? Have I misunderstood something about the nature of the problem? I'm not very familiar with the details of how the clipboard handling is implemented in Cygwin/X (though I do know that there is a choice of the external xwinclip application and the internal -clipboard handling). The way applications like Exceed seem to do it is by relinquishing clipboard ownership on losing focus, and reacquiring the clipboard on getting the focus. Perhaps this approach will also work for Cygwin/X? Igor It might work, but that would require all X applications to implement a workaround for what appears to be a Cygwin X bug. This is the main reason the Vim owner wouldn't include my patch, even though it fixes the clipboard problem. I believe his reasoning is, if the fault is Cygwin X's, then so should be the remedy. While I agree in principle, I will, of course, continue to use the patch until it's fixed in Cygwin. Incidentally, you mentioned Exceed having had to come up with a workaround as well. Is this problem known to the XWin developers? I didn't see anything in the TODO, but I can't imagine that something like this hasn't been reported by now. Incidentally, the external xwinclip application is supposed to be obsolete now, I think. I believe new development may be taking place only on the integrated version, but I could be wrong. Thanks, Brett Stahlman
Re: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
In news:[EMAIL PROTECTED], Stahlman Brett typed: Igor wrote: I'm not very familiar with the details of how the clipboard handling is implemented in Cygwin/X (though I do know that there is a choice of the external xwinclip application and the internal -clipboard handling). The way applications like Exceed seem to do it is by relinquishing clipboard ownership on losing focus, and reacquiring the clipboard on getting the focus. Perhaps this approach will also work for Cygwin/X? Igor It might work, but that would require all X applications to implement a workaround for what appears to be a Cygwin X bug. This is the main reason the Vim owner wouldn't include my patch, even though it fixes the clipboard problem. I believe his reasoning is, if the fault is Cygwin X's, then so should be the remedy. While I agree in principle, I will, of course, continue to use the patch until it's fixed in Cygwin. Incidentally, you mentioned Exceed having had to come up with a workaround as well. Is this problem known to the XWin developers? I didn't see anything in the TODO, but I can't imagine that something like this hasn't been reported by now. From your response I suspect you don't know what Exceed is. It is not another X app that has worked around this problem. It is a commercial X server for Windows. Igor is suggesting how that other X server may have worked around this problem for all X apps, and their approach could be copied to the Cygwin/X server. Cary -- 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: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps
On Wed, 18 Jan 2006, Stahlman Brett wrote:Recently, I built a Cygwin X-enabled Vim from the Unix sources on my Windows machine. Everything seemed to work well until I attempted to use the clipboard. The first attempt worked, but subsequent attempts to copy text in Vim and paste to a native Windows application failed. (The original text was pasted each time.) I looked into the issue, and actually wrote a patch for Unix Vim that allows me to use the clipboard normally for pasting to native Win applications. However, Bram Moolenaar of Vim insists (and I have come to agree) that the problem is not with Vim but with the Cygwin X implementation. Here's the problem as I understand it... When an X app such as Vim wants to obtain selection ownership, it calls a function such as XtOwnSelection (or the analogous toolkit-specific wrapper). Cygwin X processes this request by opening the Windows clipboard and calling SetClipboardData with a NULL data pointer, signifying that Windows should send a WM_RENDERFORMAT message when selection data is required for pasting into a native Windows application. This works fine for the first selection. The problem occurs when the user of the X app returns to the X app and changes the selection. In general, the X app will not make another call to XtOwnSelection (or the analogous function) because it already owns the selection and assumes it will communicate the changed data to X only when its callback function is called; i.e., when the selection is requested by another app. Unfortunately, the callback will not be called upon subsequent paste attempts for the following reason: Windows sends the WM_RENDERFORMAT message to Cygwin X's xwinclip window if and only if it believes the data it received in response to the last WM_RENDERFORMAT message is no longer valid. From Windows' standpoint, if there have been no intervening calls to OpenClipboard / SetClipboardData, the clipboard is unchanged, and there's no reason to send another WM_RENDERFORMAT message to the clipboard owner (xwinclip)! Thus, once a given X app owns the selection, subsequent paste operations into a native Windows application will always result in a paste of the initial selection made in the X app! The data pasted into Windows apps will not change until the selection owner changes. The patch I implemented for Vim worked by forcing a change of selection owner every time the selection within Vim changed. The solution was a bit messy, as it required ignoring the lose selection callback, and in the case of GTK, required processing X events between the call to disown and own selection. Also, this solution is inefficient, as multiple messages (e.g., WM_DESTROYCLIPBOARD, WM_DRAWCLIPBOARD) result from every change of selection, and the selection may change rapidly when, for example, you're selecting text with the mouse. Bram's other argument against expecting X applications to implement workarounds such as this is that it's not supposed to be necessary. There is no requirement that an X app make a call into X every time the selection changes. His suggestion (if I understood it correctly), which I believe is very feasible, is to have XWin re-call SetClipboardData with a NULL data pointer after processing each and every WM_RENDERFORMAT message. This would effectively invalidate the data in the clipboard after each time it was requested, forcing Windows to request it from xwinclip every time the user of a Windows app performs a paste. Is there any reason why this solution is not feasible? Have I misunderstood something about the nature of the problem? I'm not very familiar with the details of how the clipboard handling is implemented in Cygwin/X (though I do know that there is a choice of the external xwinclip application and the internal -clipboard handling). The way applications like Exceed seem to do it is by relinquishing clipboard ownership on losing focus, and reacquiring the clipboard on getting the focus. Perhaps this approach will also work for Cygwin/X? Igor It might work, but that would require all X applications to implement a workaround for what appears to be a Cygwin X bug. I think you misunderstood my point. What I was saying was that the X server relinquishes the clipboard upon *any* of the X applications on that server losing focus to a Windows application, and then reacquires it whenever the focus comes back to any X application on that display. Now that I know what Exceed is, I believe I understand better what you propose. However, I see some problems with basing Windows clipboard calls upon window focus. Specifically, clipboard ownership should change only in response to a copy in Windows or a selection change or copy in an X app. Consider the following scenario: you copy some text in an X app, then go to a Windows
