This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: Xwinclip doesn't work with Konsole
- From: Harold L Hunt II <huntharo at msu dot edu>
- To: cygwin-xfree at cygwin dot com
- Date: Fri, 22 Nov 2002 14:05:28 -0500
- Subject: Re: Xwinclip doesn't work with Konsole
- References: <F124WrzKBaUmjXjYg2c00016117@hotmail.com>
- Reply-to: cygwin-xfree at cygwin dot com
Chris,
I'd have to disagree in a big way. xterm, dtterm, nedit, netscape ,
and countless other X applictions that behave in the right way won't
because xwinclip breaks the standard by reclaiming ownership. I've
tested your release with at least the above and it causes
functionality issues with anything that uses the selection.
Run these same applications with xclipboard and see if the behavior is
similar. If it is, then I say it is simply a problem with the way that
the X clipboard system is designed and we leave it at that.
If, on the other hand, the applications work fine with xclipboard, then
maybe we will be able to do a better job of handling the selections.
We are not doing a very good job of figuring out how the commercial X
applications out there handle clipboard integration. They *never* grab
the primary selection and they always have the most recently selected
text from either clipboard. Maybe they are doing this through polling,
which we are trying to avoid, but I am not even sure how polling would
solve the problem (unless you poll for the selection, compare it to the
old data, and act accordingly, which would put a huge demand on network
bandwidth...).
It is our problem (well anyone who wants to use xwinclip) and it
should be fixed. The hook dll doesn't need to be used as XWin can
notify the app itself (if you have it inbuilt into xwin then multiple
instances of xwin won't work properly together (although I'm not sure
they do anyway), i'm talking about running xwin more than once not a
screen option).
Oh please. Integrating the clipboard support into the XWin.exe
executable is not going to forbid it from working with multiple screens
run by one executable, nor is it going to forbid multiple instances of
XWin.exe. You might have to program a little more carefully, but there
is nothing about having the functionality present in XWin.exe that
prevents anything from working correctly.
You have mentioned before that X-Win32 is using an Xt-app for their
clipboard support... but I have never noticed such an app. I have
always been under the impression that the cipbard support is integrated
into X-Win32's executable. In any case, we are unlikely to be able to
use Xt because we have to interleave handling of Win32 message with X
events... trying to do that with Xt may be difficult if not impossible.
There is nothing to say that we cannot handle the selections exactly as
Xt does, and doing so does not mean that we actually have to use Xt.
Shoot... we have the source code to Xt, so it isn't like something is
stopping us from understanding what Xt is doing.
I can remove the hook by patching xwin to send out WM_ACTIVATE
message's to a single xwinclip instance (this of course can be run
from within XWin anyway). But I think that's not what you want either.
I just want a solution that works identically to the dozen or so
commerical implementations that have conquered this very problem. I
won't be satisfied until we have clipboard support that rivals the
commercial X Servers for MS Windows.
Harold