Xwinclip doesn't work with Konsole

[Harold L Hunt II]

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