This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: xwinclip re selection polling
- From: "Chris Twiner" <c_twiner at hotmail dot com>
- To: cygwin-xfree at cygwin dot com
- Date: Fri, 30 Aug 2002 10:49:23 +0000
- Subject: Re: xwinclip re selection polling
- Bcc:
- Reply-to: cygwin-xfree at cygwin 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