Re: xwinclip test 6 hacked to leave selection untouched
Robert, First, this might be really cool. I had code in xwinclip a long time ago that watched the Windows clipboard and did almost exactly the same thing that you have done... except that our processing of Windows messages was not yet correct so xwinclip ended up hanging when its message queue overflowed. Now that the message processing is fixed this new patch should work well. I won't have a chance to test this until tonight or later. One side note though... please do not call your xwinclip releases test7, or test8, etc. as this will create a great amount of confusion when trying to determine if a user has a problem with an official release or an independent developer's release. Call them something like xwincip-robf1.tgz. Thanks for the patch, Harold Robert Fenk wrote: Hi, I found it quite annoying that xwinclip-test6 was grabbing the ownership of the selection every-time it looses it while IMHO it should just grab it when there is a new selection in the MS-Windows clipboard. Grabbing means the original application is loosing it and with xterm and xemacs it means that the selection is really lost, dehighlighted and not available anymore. So I did some googling how to detect clipboard changes on MS-Windows and added the code for this to wndproc.c and modified xevents.c to just grab the selection if a MS-Windows clipboard change is detected which is not caused by xwinclip itself (this part is really a hack). The code might be helpful for those working on improved xwinclip versions, but I do not have any intention on more hacking. I actually have no idea about MS-Windows API and X11 so there are probably new bugs ... http://www.robf.de/Hacking/xwinclip-test7.tgz Bye Robert PS: I have not subscribed to this list so you should address questions with a CC to me.
Re: xwinclip test 6 hacked to leave selection untouched
Robert, Hmm... I forgot that not grabbing the selection causes the problem that you mention below, namely, that we are no longer notified of further changes to the X Selection. In that case, your patch won't make much of a difference, as there is already an earlier version of xwinclip that has that precise behavior. It does not make much sense to toggle back and forth between releasing verions that do or do not grab the selection. There must be some part of the X clipboard mechanism that we just are not understanding. I picked up two X Window System books today from the ACM book sale on campus today... perhaps one of these will have a better description of the clipboard system than the other books I have. Harold Robert Fenk wrote: On Thursday, November 14, 2002 at 14:19:37, Harold L Hunt II wrote: [...] One side note though... please do not call your xwinclip releases test7, or test8, etc. as this will create a great amount of confusion when trying to determine if a user has a problem with an official release or an independent developer's release. Call them something like xwincip-robf1.tgz. Well you are right, I just was about to let you know without knowing your email and thinking too much. I probably will remove the file from my homepage tomorrow. Thanks for the patch, Sorry for not providing a patch, but the modified code, I had been reindenting it ... ;/ but you should be able to create a diff with --irgnore-all-space ... Anyway some more notes on the changes: The MS$-Code is from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/DataExchange/Clipboard/UsingtheClipboard.asp To detect selection changes in X11 I used the PropertyNotify event from the RootWindow (XSelectInput in xwinclip.c) if event.xproperty.atom != XA_CUT_BUFFER0 which I just assumed to be right when looking at "xev -id root" ... the problem is that you do not get a SelectionNotify anymore if you do not hold the selection ... Bye Robert
Re: xwinclip test 6 hacked to leave selection untouched
On Thursday, November 14, 2002 at 14:19:37, Harold L Hunt II wrote: [...] > One side note though... please do not call your xwinclip releases > test7, or test8, etc. as this will create a great amount of > confusion when trying to determine if a user has a problem with an > official release or an independent developer's release. Call them > something like xwincip-robf1.tgz. [...] http://www.robf.de/Hacking/xwinclip-test6-robf1.tar.gz Without any warranty and support ;c) Cheers Robert
Re: xwinclip test 6 hacked to leave selection untouched
I installed your xwinclip and it works fine. But in rootless mode I noticed that every time when the mouse enters a X-window the entry point is marked with semi-transparent darkgray square (~40 pixels). Not a problem - but ugly ;) Frank-Michael Cygwin Win95/NT Configuration Diagnostics Current System Time: Fri Nov 15 11:51:28 2002 Windows XP Home Edition Ver 5.1 Build 2600 Path: . c:\home\moser\scripts\cygwin c:\home\moser\scripts c:\home\moser\bin\cygwin c:\home\moser\bin c:\home\moser\work\bin . C:\jdk\1.3.1\bin C:\cygwin\usr\X11R6\bin C:\cygwin\bin\X11 C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin . c:\home\moser\scripts\cygwin c:\home\moser\scripts c:\home\moser\bin\cygwin c:\home\moser\bin c:\home\moser\work\bin . C:\jdk\1.3.1\bin C:\cygwin\usr\X11R6\bin C:\cygwin\bin\X11 C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin . x:\bin x:\usr\X11R6\bin c:\Programme\system c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Programme\Network Associates\PGPcmdln SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS CYGWIN = `nontsec nosmbntsec' HOME = `c:\home\moser' MAKE_MODE = `unix' PWD = `/home/moser' USER = `moser' Use `-r' to scan registry a: fd N/AN/A c: hd NTFS 28607Mb 76% CP CS UN PA FC PIP d: cd N/AN/A e: cd N/AN/A h: hd NTFS 28607Mb 76% CP CS UN PA FC PIP m: hd NTFS 28607Mb 76% CP CS UN PA FC PIP n: net NTFS 16042Mb 96% CP CSPAILVM-Bilder p: net NTFS 16042Mb 96% CP CSPAExport s: net NTFS 51095Mb 87% CP CSPAsoftware t: net NTFS 16042Mb 96% CP CSPATransfer u: net NTFS 51095Mb 87% CP CSPAmoser v: hd NTFS 28607Mb 76% CP CS UN PA FC PIP w: net NTFS 51095Mb 87% CP CSPAdecodon x: hd NTFS 28607Mb 76% CP CS UN PA FC PIP y: hd NTFS 28607Mb 76% CP CS UN PA FC PIP z: hd NTFS 28607Mb 76% CP CS UN PA FC PIP C:\cygwin / system binmode \\dagobert\moser /home/gustav/mosersystem binmode \\dagobert\software/home/public/software system binmode \\dagobert\transfer/home/public/transfer system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode \\dagobert\cvsroot /usr/local/cvsrootsystem binmode C:\jdk\1.3.1 /usr/local/java system binmode C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode . /cygdrive userbinmode,cygdrive Found: C:\cygwin\bin\bash.exe Found: x:\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: x:\bin\cat.exe Found: C:\cygwin\bin\cpp.exe Found: x:\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: x:\bin\find.exe Found: C:\cygwin\bin\gcc.exe Found: x:\bin\gcc.exe Found: C:\cygwin\bin\gdb.exe Found: x:\bin\gdb.exe Found: C:\cygwin\bin\ld.exe Found: x:\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: x:\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: x:\bin\make.exe Found: C:\cygwin\bin\sh.exe Found: x:\bin\sh.exe 41k 2002/05/14 C:\cygwin\usr\X11R6\bin\cygPropList-0.dll 58k 2002/05/07 C:\cygwin\bin\cygbz2-1.dll 54k 2002/01/27 C:\cygwin\bin\cygbz21.0.dll 6k 2002/06/24 C:\cygwin\bin\cygcharset-1.dll 643k 2002/11/09 C:\cygwin\bin\cygcrypto.dll 475k 2002/10/11 C:\cygwin\bin\cygcurl-2.dll 50k 2002/03/17 C:\cygwin\bin\cygexslt-0.dll 45k 2001/04/25 C:\cygwin\bin\cygform5.dll 35k 2002/01/09 C:\cygwin\bin\cygform6.dll 19k 2002/02/20 C:\cygwin\bin\cyggdbm.dll 17k 2001/06/28 C:\cygwin\bin\cyghistory4.dll 20k 2002/10/10 C:\cygwin\bin\cyghistory5.dll 929k 2002/06/24 C:\cygwin\bin\cygiconv-2.dll 22k 2001/12/13 C:\cygwin\bin\cygintl-1.dll 28k 2002/09/20 C:\cygwin\bin\cygintl-2.dll 21k 2001/06/20 C:\cygwin\bin\cygintl.dll 81k 2000/12/05 C:\cygwin\bin\cygitcl30.dll 35k 2000/12/05 C:\cygwin\bin\cygitk30.dll 45k 2002/02/08 C:\cygwin\bin\cygjbig1.dll 119k 2002/02/09 C:\cygwin\bin\cygjpeg6b.dll 59k 2002/09/20 C:\cygwin\bin\cygkpathsea-3-3-7.dll 25k 2002/07/16 C:\cygwin\bin\cygltdl-3.dll 26k 2001/04/25 C:\cygwin\bin\cygmenu5.dll 20k 2002/01/09 C:\cygwin\bin\cygmenu6.dll 156k 2001/04/25 C:\cygwin\bin\cygncurses++5.dll 175k 2002/01/09 C:\cygwin\bin\cygncurses++6.dll 226k 2001/04/25 C:\cygwin\bin\cygncurses5.dll 202k 2002/01/09 C:\cygwin\bin\cygncurses6.dll 15k 2001/04/25 C:\cygwin\bin\cygpanel5.dll 12k 2002/01/09 C:\cygwin\bin\cygpanel6.dll 40k 2001/1
Re: xwinclip test 6 hacked to leave selection untouched
I have not subscribed to cygwin-xfree and I will not ... On Thursday, November 14, 2002 at 18:50:55, Harold L Hunt II wrote: > Hmm... I forgot that not grabbing the selection causes the > problem that you mention below, namely, that we are no > longer notified of further changes to the X Selection. Dear Harold, the event PropertyNotify with event.xproperty.atom == XA_CUT_BUFFER is the solution (hopefully) ... give it a try! I could not find anything about X11 selection change detection as for MS-windows, but I have been using the event above to detect changes and at least for the applications (xterm/xemacs) I am using it seems to work well! They cause this event for the root window in case of a selection change and so xwinclip knows that it has to grab the new content and it does not require to grab the selection ownership!!! > In that case, your patch won't make much of a difference, as > there is already an earlier version of xwinclip that has > that precise behavior. It does not make much sense to toggle > back and forth between releasing verions that do or do not > grab the selection. I have no idea about the earlier version, but I think mine is different since it is detecting changes without grabbing ownership of the selection!
Re: xwinclip test 6 hacked to leave selection untouched
Hi, I'm curious has it been forgotten that I already fixed the selection grabbing over two months ago? Either way the latest code does the clipboard chain stuff and handles multiple windows ( -screen option), and some wierd bug were it doesn't free the dll properly. I can't get it to link properly on gcc 3.2. The problem being the -mno_cygwin option doesn't seem to work. The dll must be without cygwin1.dll given that as a default it is not placed inside ?:\windows\system. Maybe this is a point for another list. If the latest code is wanted I'll post it, I'm pretty much finished with what I want to do with it. I can't for example see the point in spending much more time on it if it never get's included. Chris _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: xwinclip test 6 hacked to leave selection untouched
Chris, From what I understand, you are grabbing ownership of the selection when Cygwin/XFree86 loses focus... that is not the correct solution, as other X Server on Windows implementations out there (not to name any names) are able to watch the X selection without taking ownership of it ever. It sounds likes we need to watch the selection on the root window, rather than stealing it for our own. If you did this, then I misunderstood what you were trying to say. However, I doubt that you did this because grabbing ownership of the selection when we lose focus would be unnecessary. I wait until a solution looks clean before I do anything with it, and stealing ownership on losing focus didn't look like much of a solution. Harold Chris Twiner wrote: Hi, I'm curious has it been forgotten that I already fixed the selection grabbing over two months ago? Either way the latest code does the clipboard chain stuff and handles multiple windows ( -screen option), and some wierd bug were it doesn't free the dll properly. I can't get it to link properly on gcc 3.2. The problem being the -mno_cygwin option doesn't seem to work. The dll must be without cygwin1.dll given that as a default it is not placed inside ?:\windows\system. Maybe this is a point for another list. If the latest code is wanted I'll post it, I'm pretty much finished with what I want to do with it. I can't for example see the point in spending much more time on it if it never get's included. Chris _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: xwinclip test 6 hacked to leave selection untouched
Hi Harold, From what I understand, you are grabbing ownership of the selection when Cygwin/XFree86 loses focus... that is not the correct solution, Nope, it only grabs X selection when both the windows clipboard has changed (in latest code) and any "cygwin/xfree86" class window is activated. I.e. it won't grab it if a user moves from one "cygwin/xfree86" to another. When the "cygwin/xfree86" looses focus it first looks for XA_PRIMARY and then XA_SECONDARY and then clipboard, not that the clipboard code works with motif apps. The basic one window code (no clipboard chain) was there two months ago and posted to the group. I.e. it fixed what was broken in test6 and fixed again by the recent poster. as other X Server on Windows implementations out there (not to name any names) are able to watch the X selection without taking ownership of it ever. Which was the whole point of my fixes, you yourself claimed you could not see what was wrong with test6 "prove to me with code" was your response. So I did, you said "great" it looks like it works, thanks for the contributions I'll put it into a new test release, however you were busy and it would take a while. Which from the level of involvement you have with cygwin was all too reasonable. It sounds likes we need to watch the selection on the root window, rather than stealing it for our own. If you did this, then I misunderstood what you were trying to say. However, I doubt that you did this because grabbing ownership of the selection when we lose focus would be unnecessary. Indeed I did. It never grabbed the selection when the focus was lost, only when the window was activated again. i.e. you have gone into windows and the clipboard is different so grab the windows clipboard. The current version only does this when the clipboard has changed (And across -screen's). I had tried to explain this before (as had other posters) but you didn't see anything was wrong, so I made it work in a consistent fashion with windows and most x servers and so it wouldn't break nedit (main motivation). I wait until a solution looks clean before I do anything with it, and stealing ownership on losing focus didn't look like much of a solution. Again it was only on gaining of activation, and you didn't at the time see anything was wrong with the test6 code. You had wanted it external when you mentioned this (or internal with a disabling switch). My solution was designed from the outset not to intefere with the inner workings of the xserver and to be within the X selection system, something that commercial solutions obviously aren't limited by. Chris _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: xwinclip test 6 hacked to leave selection untouched
Chris, Well, if you solution is everthing you claim, then you certainly have not been promoting it correctly. The impression I have gathered is that it requires hooks to watch messages for the XWin.exe windows, whereas today's solution does not require such hooks. I have really been waiting for a solution that does not require such hooks. If your solution no longer requires such hooks, then you did a poor job of communicating that fact. Harold Chris Twiner wrote: Hi Harold, From what I understand, you are grabbing ownership of the selection when Cygwin/XFree86 loses focus... that is not the correct solution, Nope, it only grabs X selection when both the windows clipboard has changed (in latest code) and any "cygwin/xfree86" class window is activated. I.e. it won't grab it if a user moves from one "cygwin/xfree86" to another. When the "cygwin/xfree86" looses focus it first looks for XA_PRIMARY and then XA_SECONDARY and then clipboard, not that the clipboard code works with motif apps. The basic one window code (no clipboard chain) was there two months ago and posted to the group. I.e. it fixed what was broken in test6 and fixed again by the recent poster. as other X Server on Windows implementations out there (not to name any names) are able to watch the X selection without taking ownership of it ever. Which was the whole point of my fixes, you yourself claimed you could not see what was wrong with test6 "prove to me with code" was your response. So I did, you said "great" it looks like it works, thanks for the contributions I'll put it into a new test release, however you were busy and it would take a while. Which from the level of involvement you have with cygwin was all too reasonable. It sounds likes we need to watch the selection on the root window, rather than stealing it for our own. If you did this, then I misunderstood what you were trying to say. However, I doubt that you did this because grabbing ownership of the selection when we lose focus would be unnecessary. Indeed I did. It never grabbed the selection when the focus was lost, only when the window was activated again. i.e. you have gone into windows and the clipboard is different so grab the windows clipboard. The current version only does this when the clipboard has changed (And across -screen's). I had tried to explain this before (as had other posters) but you didn't see anything was wrong, so I made it work in a consistent fashion with windows and most x servers and so it wouldn't break nedit (main motivation). I wait until a solution looks clean before I do anything with it, and stealing ownership on losing focus didn't look like much of a solution. Again it was only on gaining of activation, and you didn't at the time see anything was wrong with the test6 code. You had wanted it external when you mentioned this (or internal with a disabling switch). My solution was designed from the outset not to intefere with the inner workings of the xserver and to be within the X selection system, something that commercial solutions obviously aren't limited by. Chris _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: xwinclip test 6 hacked to leave selection untouched
Well, if you solution is everthing you claim, then you certainly have not >been promoting it correctly. It's my fault that you have forgotten it? I don't thinks so. If you did not want to use it then you should have said a long time ago before I wasted days on it. The impression I have gathered is that it requires hooks to watch >messages for the XWin.exe windows, whereas today's solution does not >require such hooks. I have really been waiting for a solution that does >not require such hooks. If your solution no longer requires such hooks, >then you did a poor job of communicating that fact. Nothing has changed about it using hooks. Nothing at all. If his solution does work/ not had time to try it out. Then at least the jmp's and signal handling should still be of some use. Also : https://listman.redhat.com/pipermail/xdg-list/2000-October/05.html And the reading I did whilst creating the changes would indicate this only happens for applications that explicitly choose it too. Motif apps don't either it would seem. Chris _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
Re: xwinclip test 6 hacked to leave selection untouched
Robert, In an intial test of your patch, I noticed that your patch, after the first selection, only tends to grab every other selection that I make on both the Windows clipboard and the X clipboard. For example, I go into emacs under X and select a region, then I go to emacs under Windows and paste the selection with the middle mouse button; the first time it works fine; now I select some text in emacs under Windows (which causes the selection in emacs under X to be unhighlighted) and go to paste it in emacs under X, but instead of getting the new selection coming from emacs under Windows I instead get the same old selection from emacs under X. Now, if I go back to emacs under Windows and select something else, then when I go to emacs under X it pastes the correct selection. This process repeats and it always seems that every-other selection is gotten but that the ones in between are never picked up. Any ideas? Harold
RE: xwinclip test 6 hacked to leave selection untouched
Robert, I have been trying to figure out how your patch to xwinclip works. In particular, I was wondering how it got notification that the selection had changed when it was owned by another window. I can now sum up your changes in a sentence: XA_CUT_BUFFER0 is watched for changes and the selection is copied to the Windows clipboard whenever cut buffer 0 is changed. That may not be a completely clean way to solve the problem forever, but it does work, at the very least. Harold
