Xwinclip doesn't work with Konsole

[Chris Twiner]

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

Well actually I can't even get the cygwin one to run let alone do anything.  
It pops up a small window with a very confused button set then shows cancel 
or something similar every time I try to use it.

Using the openwin (solaris) xclipboard these applications work fine, the 
selection is fine and everything works as expected.

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

Only ever when you leave one of their windows.  Don't forget that they, like 
you know when you're window is left.  That is the time to find out if 
anything has been grabbed.  Also I'm fairly sure that most messages go 
through the X server so it shouldn't be very difficult to trap drags, 
ctrl+c's etc. Or more likely the real message ids.

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

I doubt polling would solve much.  Either way you are still causing 
unnecessary bandwith hogging when you steal ownership, not much most of the 
time but heh.

More importantly the way that most X users expect the selection system to 
work (again as a user) is like my fix had made i.e. don't grab the 
selection.  As a side point, yes I prefer my version of xwinclip to exceeds 
rather poor clipboard handling, including the recent release.  Plus it 
always crashes and it's dead slow.  I prefer cygwin/xfree86 by a long shot.

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

The oh please is a little childish don't you think?  I never said it would 
forbid anything.  But in terms of real issues that would have to be tackled:

- setjmp and longjmp would not be usable within the xwin, they work on stack 
unwinding and would unwind the whole stack (pos solution to run as a thread 
but xlib doesn't like that very much).
- if you do have multiple instances of the code that does the selection 
handling you will have to use ipc mechanisms to handle the change in 
selection loop (xwinclip a and b).  A notices that an applicaiton in it's 
instance has changed the selection, it copies it to the clipboard.  B 
notices that the clipboard has changed and claims ownership, a notices that 
an app....  If R4 programmers could do it, I'm sure you or I could.

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

Never said there was.

>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'm a little confused here I have never mentioned X-Win32 before in my life. 
  I did mention Klipper for KDE that I found before solving the problem of 
inter toolkit selection grabbing.  But never X-Win32.

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

As I and others have said here, the commercial ones aren't much better but 
they don't grab the selection (it's about the only good thing they do).

Either way unless you can obtain source code or a developer who worked on 
these you're stuck as to identically doing it.  The question you have to ask 
yourself is if you need to do that.  You seem dedicated to copying the 
selection every time a user highlights something.  Why?  I doubt seriously 
that commercial software is doing something so obviously wastefull.

Chris

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail