Re: xwinclip re selection polling

["Chris Twiner" <c_twiner at hotmail dot com>]

> - kill_xclip_hook.exe doesn't do anything for me. I have to use 
> kill_xwinclip to really remove the hook, even if xwinclip is already dead.
I saw that a few times as well.  I'm wondering wether a new message needs to 
be sent through the hook to close it or something similar.  I'll add the 
functionality into kill_xclip_hook, the two behaviours are different in that 
if xwinclip is running then just kill_xwinclip will do the job of both 
anyway.

> - We really need to find away to automatically remove the hook without 
> having to use kill_xwinclip (or find a way to automatically call this app). 
> It took me a few minutes to remember what you said in your previous mail 
> and what I compiled before I thought about using this program. Could 
> xwinclip do the same thing than kill_xwinclip before registring itself?
I've been trying to figure a way around this.  It will always remove the 
hook if kill_xwinclip has been called, because this allows the program to 
exit gracefully.  Ctrl-c or closing the window doesn't and the signals never 
seem to work.  In essence the bit's that are important are a call to RemHook 
and to FreeLibrary from within xwinclip.  When it recieves a WM_DESTROY 
(like kill_xwinclip sends) it cleans itself up, xconnection and all.

I think until it's integrated within XWin (still think Harolds right about 
the closing of connection, I can test for the Cygwin/XFree86 window being 
closed, I can even stop it but I can't catch the xlib bombing out on a 
send/receive) it must have a windows window not a console to close properly. 
 This would allow the proper trapping of the messages.  It doesn't need to 
show anything in the window just to be a visible one.  Of course it doesn't 
stop someone killing the process but it does at least make the close work.

> - XWinclip doesn't copy what is already in the windows clipboard when it 
> starts.
Good un. Although I'm not sure it's entirely wanted behaviour.  What if you 
just start xwinclip between selection operations on the XWin x clients?  
Should it automatically clear them or is the reason you're starting xwinclip 
because you want to give them the windows clipboard.  I think it's the 
latter, I'll put it in (means owning XA_PRIMARY when it starts up, no 
biggy).

> - I don't know if it can be done but when XWin gets activated, the 
> selection should not disappears if the Windows clipboard didn't change. I 
> mean: if you select something in X, activate a Windows application, then 
> activate XWin, the selection disappear, it shouldn't.
Agreed on reflection that makes sense shouldn't be tough to fix.  See below 
re: WM_DRAWCLIPBOARD.

> That said, a thought came to me (yep, another wild guess :p). When I select 
> something in X, I can paste it as many time I want without having the 
> selection disappearing. Is it because when I "middle-click" X fake the 
> paste by sending the keystrokes matching what is in the clipboard or is it 
> because reading the content of the clipboard doesn't change the selection?
It's because clicking the middle button sends a xconvertselection that sends 
a SelectionRequest event to the owner.  The owner of the selection sends the 
data back in a SelectionNotify event. (of course this is given that I read 
the specs properly, but it seems to be the truth from the debugging 
printfs).

The original xwinclip always followed the reciept of the SelectionNotify 
event with an XSetSelectionOwner which forced the selection to be cleared 
(via a SelectionClear event).  As such whilst you could still paste as many 
times as you wanted (as xwinclip now owned the selection and handled the 
requests) you couldn't use any functions that depended on the selection 
remaining with the original owner.

> IOW, am I correct to assume that the selection disappear when an 
> application "take ownership" and that "taking ownership" mean that when a 
> process ask for the clipboard content, we will be the one asked to send it? 
> If my guess is correct, why not "take ownership" only if the Windows 
> clipboard changed and differs from the current X clipboard?... Or was 
> because xwinclip was losing the ownership that it knew that the selection 
> changed?
The Or is the right one.  It knew because it received the SelectionClear 
event.  I agree though it's really only necessary to take ownership when the 
windows clipboard is different.

> Last Chris, you may want to look at the WM_DRAWCLIPBOARD Windows event. 
> Using this feature would allow to handle Windows applications that change 
> the clipboard by themselves (ie without user intervention). I don't know 
> any but I'm not omniscient.
It seems perfect for the job.  Saves trying to evaluate the contents of the 
clipboard between the two (really convoluted as it's asynchronous you'd have 
to write a mini event loop).  I'll put that in as well, it'd make things 
that much smoother.

Thanks for the feedback some gems esp the WM_DRAWCLIPBOARD.  I didn't know 
that existed, not even a couple of years ago when Win32 API was my bible.  
Guess I never played with the clipboard enough :-).  Hopefully I'm making up 
for it now!

cheers,

Chris

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com