Re: Xwinclip doesn't work with Konsole
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
Re: Xwinclip doesn't work with Konsole
Hmm... Indeed, the clipboard thing has been irritating me for a while, can't believe i didn't spot it. Either way I can't get the thing to work yet. When I call XConvertSelection on CLIPBOARD it says there is a message (from select) but then XNextEvent doesn't process any message, very wierd. Primary still works fine. xwinclip-Test06 actually works the exact same way with Emacs... I am >pretty sure this is just because Emacs 21 finally fixed the way that >the selections were handled. So, I think we can now safely say that if >someone has an application that unhighlights the selection when >xwinclip is running: fix the *?$%ing application!!! :) 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. The next qt format will follow motif i.e. select is primary, ctrl+c (or alt+c etc) copies the highlighted text into the clipboard. This is a very standard way of doing things, and more importantly it works properly. "Fixing" them to leave the selection up breaks the normal visual feedback you get with all standard X apps, not good at all. Arrgh... I am just confused now. Is the unhighlighting of >selections our problem anymore? I am starting to think that it is not. 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). 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. Chris _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
RE: Xwinclip doesn't work with Konsole
Hi Chris Can you build the xwinclip exe and use the dll supplied (i've put the build_dll.sh in there as well)? Let me know what happens (and the output). The copy from X works just like I wrote in my previous mail to Harold (see log1), but when I try to copy from Windows, the results are unpredictable. (see log2) Thanks Jozsef, The output looks as I'd expect for Harolds reasoning. I've put in his changes for selecting the CLIPBOARD (an issue with me for a while) output but I haven't made the thing work yet. It recognises an owner and calls xconvertselection, then the flushxevents function is called but the XNextEvent doesn't show a new message. Bizarre. I'll keep trying to get clipboard working properly maybe that will be enough. chris PS (the "wierd" behaviour with pasting back the windows clipboard is because it won't claim ownership unless a windows application has changed the clipboard since the last primary selection. This is in my code only. It makes logical sense but it doesn't work the way the old one did, as far as possible it leaves XWin to do it's thing, only claiming the primary selection once the clipboard has been changed). _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
Re: Xwinclip doesn't work with Konsole
Hi! Sorry for private mail, but I am not sure I can mail to the list.. reading it from news. No problems. I had to register with the global posting list (on sources.redhat.com) to post properly, I had so many returned to me. Using the global list means you don't have to receive all message postings. Just a quick thought.. as you say "it does not use the PRIMARY selection properly", does it use the primary selection at all? According to the docs on it, yes. It's apparently a well known problem, if it is the problem that was suggested. I mean, modern X and like the CDE on solaris has two clipboards, one is for CDE, and can be accessed by apps compiled to CDE through the menus edit->copy edit->paste, while the other, in xterms, emacs and so on uses the ancient select with mouse, and paste with middle button.. Strictly speaking the acient select with mouse and paste option is the correct ICCM standard, that's why qt3 is moving to that way of operating. It's probable that it's current implementation is just using it's own wierd solution but the postings on google seem to indicate it uses both CLIPBOARD and PRIMARY so it may be it's just not using it properly. It is not like Konsole uses the alternative clipboard? Or you are supposed to use it.. Nope it's non standard. However that doesn't mean that xwinclip shouldn't be changed to work with it. Or maybe even you need to select the text, and do a edit->copy to get it to the clipboard? Could be, but I'd like to see what the latest output would be. Chris _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
RE: Xwinclip doesn't work with Konsole
Hi, Can you build the xwinclip exe and use the dll supplied (i've put the build_dll.sh in there as well)? Let me know what happens (and the output). Thanks, Chris _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail xwinclip_hook.zip Description: Zip compressed data
RE: Xwinclip doesn't work with Konsole
Hi, Thanks for the feedback, I will post another version of mine tonight (forgot to last night). Can you give me the output of my xwinclip when you run these tests? I will post the built exe and the dll for my version as well, just to remove compilation issues. It seems as though it doesn't recognise that there is a primary selection. This seems related to the qt bug but I don't know quite how to proove it. Chris _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
Re: Xwinclip doesn't work with Konsole
Hi! Damn this is interesting. Just to check (I don't have kde available) this when you say copy/paste do you mean the edit menu copy and paste? No. good good. Or do you mean highlight in Konsole and then use the middle button. Yes, this is what I meant. What does the output of my xwinclip have in it? does it show something like : no xa_primary owner or maybe XToWindows XA_PRIMARY convertselect() failed It would mean that there is some dodgy non-standard activity going on or that the format can't be converted. Chris _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Re: Xwinclip doesn't work with Konsole
Thanks Jozsef, That's perfect information. From what I can tell (quick research) it uses CLIPBOARD and PRIMARY. Sorry, this I don't understand, what this sentence means. Can you explain it? I think so, the Konsole app doesn't seem to use the PRIMARY selection properly (i.e. in a standard way), that is why test6 doesn't automatically remove the selection from it. The primary selection is when you highlight something in xterm and then (whilst it is still highlighted) use the middle button to click in another xterm (or the same one, or another compliant x application). This is the standard way to perform cutting and pasting. This works properly with both versions of xwinclip for compliant applications. Just to check (I don't have kde available) this when you say copy/paste do you mean the edit menu copy and paste? Or do you mean highlight in Konsole and then use the middle button. (although at some stage in the next few months I may get another box for linux). regards, Chris _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
Re: Xwinclip doesn't work with Konsole
I have tested the latest official release (Test6) and the hacked one from Chris Twiner, but neither works with Konsole, the console from KDE. Hi, What are you doing that makes you think it isn't working? Are you just using primary selection? From what I can tell (quick research) it uses CLIPBOARD and PRIMARY. If (with my version) the selection is still shown can you use the middle mouse button to "paste" it into another X app, like xterm? If so then it should be usable with both mine and test6. does test6 clear the selection after you select it? Chris _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
re: Direction of xwinclip
I now remember what it was that I did not like: Ownership of the X selection is grabbed when XWin.exe loses focus. Is that correct? No. It only takes ownership selection when XWin is gaining activation (and not from another window). When Xwin looses activation (and therefore focus) it merely grabs whatever is in the selections, if anything, and puts it into the windows clipboard. Robert's method of watching for changes in XA_CUT_BUFFER0 might be hack, but I think it is probably closer to what other X Servers for Windows are doing, as those other X Server do not grab ownership of the X selection when they lose the focus. Neither does my code, but see later... Have you got any objections to watching for changes in XA_CUT_BUFFER0 as a signal that we should request another copy of the X selection? Yes I have, the ICCM standard says don't use it in new applications and the rest of the x development community says don't use it in new applications. Seemingly only a few do. Motif apps have some wierd logic for working out wether to try and use it but they don't use it directly (they've got their own wierd and wonderful way of doing things for CLIPBOARD). Basically as the ICCM says it's obsolete. You can write a compliant X selection app that works with PRIMARY without problems but never uses the cut buffers. How many applications have you tried it with, sorry I can't try it at mine, gcc's specs don't seem to work for my box (or the work box I have it on). If we decide to go with the XA_CUT_BUFFER0 hack, then there will probably need to be only one more release of xwinclip. After that we can concentrate on integrating the clipboard support into XWin.exe. I think that it would be usefull (possibly as thats the way xceed works, when it does, to make it an xt/xm app as well) so that we can get the motif clipboard if it's being used. However within XWin it may not be the best approach either way, as all messages go through the xserver anyway should not a simple hook into the server code be better then making a client within a server (and having to look at threading it or more complicated setjmp's). By the way... I like the setjmp/longjmp stuff... I thought it was two assembly language instructions that were used. Imagine my surprise when I saw setjmp.h and realized that setjmp and longjmp were (used like) functions. That is a heck of a lot easier than I had thought it would be. Glad it could help. Thanks for your contributions Chris. cheers, 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
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
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: how does xwin resolve ip addresses
Ok, problem resolved. After much digging around and non-help from 3Com I have sussed the damn thing out. When such a thing happens, either the ipconfig not returning the whole information or a 20106 error in the system log (doesn't seem to matter if it's talking about a different interface), the RRAS service is the damned culprit. So answer was disable the damn thing. Thanks to all that helped and many thanks to Ago, Chris _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
right mouse button again, motif on solaris
Hi All, An application, Razor (Motif) that I'm running won't allow the right button to work. After investigation this appears to be a bug in the Motif libraries within Solaris. However as it appears different on different Xservers the common factor seems to be the mouse setting. A post : http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3717E713.BBD3D2F1%40soest.hawaii.edu&rnum=2&prev=/groups%3Fq%3Dmotif%2Bproblem%2Bright%2Bmouse%2Bbutton%2Bsolaris%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den Seems to indicate that the server tells the client how many mouse buttons are supported. This seems to be a motif issue. Under NEdit for example it is possible to get the right mouse button menu by disabling num-lock, scoll-lock and caps-lock. Of course Razor doesn't work this way. (basic problem is drag and drop doesn't work over ssh, since it uses it's own protocol, so a right mouse button is the only other way to work it). Exceed doesn't share the problem cygwin has. Cygwin's problem seems very similar to the problem indicated by the above post. i.e. cygwin tells the motif version there are X number of buttons and it chooses the last button for right button as default. Is there any way of checking what an individual application believes or indeed checking/changing what the cygwin is telling the clients? Your's confused further, Chris _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
Re: Problems with xwinclip version 0.5/0.6
I have installed the xwinclip-Test06, but the selection not only >dissapears, after I release the mouse button, but it flashes continously, and I can't paste the selection either under X, nor in windows. Has anybody any ideea, why is this so? The second problem may be related to the first, given the flashing continuously. It seems like the application you are using remotely tries to capture the x primary selection as well. This release of xwinclip claims the x selection as soon as a selection has been made. The other application may be doing the same, hence the continuous flashing. You can try using the version I uploaded to the list. It needs to be compiled though, and if you have the latest version of cygwin it probably won't work. I should be able to release a new version of the xwinclip to the mailing list tonight which should work with the latest version, I hope. Regards, Chris _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Re: how does xwin resolve ip addresses
Hi, At 3Com's behest I tried the card in another laptop that had another installation of the card: Yes the card works in another laptop, an xp home one on the same network. Also the ipconfig works on this machine as well. It looks therefore like a driver problem, either a bad installation on my part or some conflicting software. I will do the following : 1) re-install the software 2) check dll dependencies and versions between the two machines I'll reply with the results. , and I'll do the same here. Ago, I'll try these changes first because it looks much like a bad software installation and nothing to do with cygwin. Unless you'd like to try and get it working with this installation first, in which case I'll delay the changes. Chris _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: how does xwin resolve ip addresses
An additional bit of information, IIS can use the ip address to serve web pages. ipconfig is still of course broken. Chris _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Re: how does xwin resolve ip addresses
Hi Ago, Tried it, but it made no difference. Chris _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
Re: how does xwin resolve ip addresses
here are the results of the latest :
ls_netdev $Id: ls_netdev.c,v 1.3 2002/11/04 21:59:03 ago Exp $
OS Version: Windows NT 5.1 Build 2600
Querying devices using ioctl
lo: family=TCP/IP (0) addr=127.0.0.1
eth0: family=TCP/IP (0) addr=0.0.0.0
Querying devices using internal function
// Dumping IpAddrTable
// IPADDRROW
dwAddr=
dwIndex=65540
dwMask=
dwBCastAddr=0001
dwReasmSize=65535
// IFROW
wszName=
dwIndex=65540
dwType=6
bDescr=Intel 8255x-based PCI Ethernet Adapter (10/100)
// IPADDRROW
dwAddr=
dwIndex=65541
dwMask=
dwBCastAddr=0001
dwReasmSize=65535
// IFROW
wszName=
dwIndex=65541
dwType=6
bDescr=3Com 3CRSHPW_96 Wireless LAN PC Card
// IPADDRROW
dwAddr=017f
dwIndex=1
dwMask=00ff
dwBCastAddr=0001
dwReasmSize=65535
// IFROW
wszName=
dwIndex=1
dwType=24
bDescr=MS TCP Loopback interface
// Dumping IfTable
wszName=Loopback
dwIndex=1
dwType=24
bDescr=Internal loopback interface for 127.0.0 network
wszName={562C1C1F-F3B0-49E1-98D6-C44DF1084DD8}
dwIndex=65540
dwType=6
bDescr=Intel 8255x-based PCI Ethernet Adapter (10/100)
eth0: family=TCP/IP (0) addr=0.0.0.0
lo: family=TCP/IP (0) addr=127.0.0.1
And just for completeness the route print:
c:\home\Chris>route print
===
Interface List
0x1 ... MS TCP Loopback interface
0x2 ...02 00 4c 4f 4f 50 .. Microsoft Loopback Adapter
0x10004 ...00 20 e0 70 70 16 .. Intel 8255x-based PCI Ethernet Adapter
(10/1
00)
0x10005 ...00 04 75 c4 55 6e .. 3Com 3CRSHPW_96 Wireless LAN PC Card
===
===
Active Routes:
Network DestinationNetmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1192.168.1.35 30
10.0.0.0255.0.0.010.10.1.1 10.10.1.1 30
10.10.1.1 255.255.255.255127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.25510.10.1.1 10.10.1.1 30
127.0.0.0255.0.0.0127.0.0.1 127.0.0.1 1
192.168.1.0255.255.255.0 192.168.1.35192.168.1.35 30
192.168.1.35 255.255.255.255127.0.0.1 127.0.0.1 30
192.168.1.255 255.255.255.255 192.168.1.35192.168.1.35 30
224.0.0.0240.0.0.010.10.1.1 10.10.1.1 30
224.0.0.0240.0.0.0 192.168.1.35192.168.1.35 30
255.255.255.255 255.255.255.25510.10.1.1 10.10.1.1 1
255.255.255.255 255.255.255.25510.10.1.1 10.10.1.1 1
255.255.255.255 255.255.255.255 192.168.1.35 10004 1
255.255.255.255 255.255.255.255 192.168.1.35192.168.1.35 1
Default Gateway: 192.168.1.1
===
Persistent Routes:
None
Hope it helps.
3com rather quickly referred me to the cygwin/xfree86 documentation so I'll
not hold out much hope of useful help from them.
Chris
_
Unlimited Internet access -- and 2 months free! Try MSN.
http://resourcecenter.msn.com/access/plans/2monthsfree.asp
Re: how does xwin resolve ip addresses
> Bad luck. It seems the ip address is correctly setup, but there is no > interface configured. Maybe reinstalling the drivers for the wireless > card will help. > > I've searched the MSDN but there is no comment for the GetIfTable function > that it would not report wireless interfaces. I'be build a new version, which queries the interface for each ip address. Can you please try it too? http://www-usercgi.tu-chemnitz.de/~goal/xfree/ls_netdev.tar.gz Hi Ago, I'll try it later today (it's at home, I'm at work :). Chris _ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp
Re: how does xwin resolve ip addresses
Hi Harold, I seem to have the latest drivers, I checked a couple of weeks ago, no harm in doing so on a regular basis. It just strikes me as weird that although I can telnet into a box over it I can't start a server on it. Add that to ipconfig /all and it makes it very confusing. I'll send a query to 3com. cheers, Chris _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp
how does xwin resolve ip addresses
Hi All, I have a problem using a wireless card (3com) on my home network. I have a basic wireless setup and a switched setup (for my servers). When using the wireless card I can use the internet fully and most applications are happy with it. Bizarly though ipconfig /all doesn't list the wireless card as an ip adapter. When trying to use cygwin/xfree on the address (given by dhcp) the xserver doesn't work i.e. no clients can bind to it. Is the discovery mechanism for the ip address using the same as ipconfig does and hence can't see it? Does anyone have similar experience? tia, Chris PS (I should get some time today to work on xwinclip, I'll tackle it on the latest release) _ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp
Re: right mouse button doesn't work (re: old subject)
Hi All, got the problem. When the num-lock is on it won't work properly in nedit: similar problem non-cygwin related: www.nedit.org slash archives slash discuss slash 2000-Mar slash 0383.html (slashed it so it would go through the spam filter) So it's possibly an application problem I'm looking at. Why it works on local and not remote I don't know. It doesn't help with the other application though. (Drag and drop and right mouse button, which works under exceed). The application is Razor by the way. chris _ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp
Re: right mouse button doesn't work (re: old subject)
Hi Harold, Just got some extra info. Rather curiously holding down ctrl and clicking the right mouse button works as expected. This further compounds the issue given that some button 3 messages are definitely getting through. cheers, Chris _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp
Re: right mouse button doesn't work (re: old subject)
Hi Harold, The address of the old message is here, http://www.cygwin.com/ml/cygwin-xfree/2001-q4/msg00272.html David Esposito is the person who said he had everything working. Just a little info, I checked xmodmap -pp and all the mappings are ok, running NEdit on the local machine (cygwin to cygwin) works fine, NEdit from the solaris box doesn't. Also some other applications that are used at work don't. Incidently there is also a drag and drop issue. The cursor changes to indicate the drag has started but the window never recieves the drop (although the initiator changes the cursor back). It's possibly the same issue. I did the xev check as well, just to make sure it was somewhere between solaris and the solaris default X server system (i.e. using nedit as a server to cygwin). cheers, Chris _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp
right mouse button doesn't work (re: old subject)
Hi All, A while ago the point was made that when using X from a solaris system to cygwin the right mouse button did not work. Mentions of recompiling x for solaris were mentioned but no conclusion was shown. Only a post by Harold that someone got it working. Suffice to say I have such a situation. It happens on my home solaris box and those at work. Whilst messing around on my own box is ok, it's definitely not for the work machines. Was any conclusion reached? Did anyone have a solution? Chris _ Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp
Re: Problems with xwinclip version 0.5/0.6
Hi Brian, Thanks for the 'extern "C"', I had forgotten to add those. If you don't mind however I'll avoid poluting the std namespace. Chris _ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp
Re: Problems with xwinclip version 0.5/0.6
Hi, A release was planned by Harold but he's very busy so it could be a while. All is now clear with regards the compiler. Indeed I used gcc 2.95 not the 3.1 release. So, the reason it fails with the can't set hook func is that the name mangling has changed. I'll investigate what it has changed to. The failed linking is a little strange but heh. At least I understand why the dynamic loading doesn't work. chris _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp
Re: Problems with xwinclip version 0.5/0.6
Hi, I can send you them directly later (I'm at work now) but.. You say it dies after the messages are displayed, do you mean that xwinclip then terminates? Or do you mean it doesn't seem to do much? Also I'm still a little confused as to why you needed to change the build dll script anyway, what release of cygwin are you using? Maybe I and the others have an older/newer version. Chris _ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp
Re: Problems with xwinclip version 0.5/0.6
Hi Volker, I notice you had a mingw error. Could you please try using the gcc provided with cygwin, as I believe myself and others use. It should remove most of the problems you're seeing as neither myself nor others seem to have them. As to the output, that's correct it's debug information to let me know what is going on message wise through the system. The ioctl statement is due to the cygwin code for the windows device explicitly mentioning setting the hwnd it listens to (or listens to all). Which doesn't really hurt anything in the code you have. After that message it should also display information in the xwinclip window about what windows and X messages are being processed involving the clipboards, again just debug information. Thank you for trying to use the code though. Chris _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp
Re: Problems with xwinclip version 0.5/0.6
Hi Volker, Can you try the version I posted last month (there were several versions but the last post holds the best version). It solves the clearing of the selection. I am suprised that the test06 solved your problem, it didn't with me or other users. I use NEdit so I have the same issue with active regions. With respect to the selection maintaining two different clipboards can you tell me if it seems to behave the same with my changes? Also if you're testing rootless mode it would be good to know if it works in that (it looks for a focus change in the root window so I am not sure it will), I haven't had time to have a look yet. Regards, Chris _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp
Re: xwinclip problem/puzzle
Unfortunately not. The version most recently posted had the ctrl+c and server reset code in place but nothing much else. Oh. It does however contain the code to handle the selections properly. I'm not sure I made that clear enough. It does what you want it to do but not much else, is what I should have said :-). When you run multiple screens do you keep the same display setting or does it need to change? If it is the same display I can get it working (by making sure the newly activated window is not a cygwin window). Do you mean multiple virtual desktops, or dual monitors? Though I Multiple virtual desktops, dual monitors didn't seem to work in any way. I.e. using the screen option on xwin.exe chris _ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp
Re: xwinclip problem/puzzle
Thanks for the referal Jehan, >And maybe Chris has a newer version now. Unfortunately not. The version most recently posted had the ctrl+c and server reset code in place but nothing much else. This I had planned to do: - get the windows clipboard only when something has changed on it (don't unnecessarily grab the x selection) - handle multiple X server screens (so you don't end up using windows as an unnecessary intermediatary clipboard system). When you run multiple screens do you keep the same display setting or does it need to change? If it is the same display I can get it working (by making sure the newly activated window is not a cygwin window). As to further dev I want to contribute but my time is tight at the moment, previously I was on a part time contract so I could devote time to xwinclip. Now I'm full time so I don't know when I'll get round to it. I will do them both, but I just can't say when. Chris _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: xwinclip
Hi Jean-Claude, >Please forgive the newbie-type question: http://xfree86.cygwin.com/devel/xwinclip/ gives a thorough explanation on how to get xwinclip running. It must be running as well as XWin. You'll see if that version is running because when you select some text the selection will dissapear and automatically be placed in the windows clipboard. Hope that helps _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: xwinclip - update and motif clipboard
>>Well according to the specs you're implementation is right. Own clipboard >>manager and grab the clipboard when it's been selected, then own it again. >> It doesn't seem to work with Motif though. No biggy, primary works v. >>well. >> >That's good to know, but why doesn't it work when we do it according >to >the >spec? :) Motif does some wierd clipboard antics and completely breaks the way it should work. Basically it stores all the entries under the root window as properties (xprop can show them). There is a kde app called klipper that handles the two properly but it involves making xwinclip an xt application for the xm stuff to work. >>Like Chris said it's suprising you can reply at all, and much appreciated. >> >No problem, I don't want people to think that I have given up or anything. Like I said, it's much appreciated, I've been busy this week with various things but I've still checked the list so it's a very good feeling to see such a reply. >which you can view via XFree86's cvsweb). Or, you could blindly >reimplement the ClipBoard chain support... Honestly I'm tempted to do that, purely because it offers the oppurtunity to have a bit more of a play. The ultra2 that was going to occupy my time just "blew a fuse" so I'm back to the free time. >It would probably be a good idea to allow the app to work with multiple >XWin sessions. But, are you doing everything properly, such as giving each XWin window a different display number and telling each instance of xwinclip which display to connect to? I'm doing that properly (although a new app starts in the old display). The problem is I'm looking for a window that says Cygwin/XFree86 which of course they all will say. It may need code in XWin to provide a differentiation of window title mentioning the display number (and env variable) or something similar. Otherwise you don't know which XWin display has lost/gained focus and which to start the xwinclip operations on. I think that would also be usefull for XWin in multiple windows as well. The user would be able to see which goes where. Possibly a user additional title as well such as "linux box" or "sun box" etc. In short how do you know which "Cygwin/XFree86" window is the one xwinclip is started for (x wise it's DISPLAY) but windows wise? Chris _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
Re: xwinclip - update and motif clipboard
>I thank you for putting so much time into developing xwinclip. It has been a pleasure anyway. >I really appreciate that you got the long-awaited setjmp lngjmp functionality implemented so that we are not killed upon X Server shutdown and restart. It's cool, I've always wanted an excuse to use them (always used c++ exceptions instead). >I don't know anymore about the CLIPBOARD than what I wrote in the xwinclip source comments, which was something to the effect of, ``help! can't find CLIPBOARD documentation, how does it work?'' Well according to the specs you're implementation is right. Own clipboard manager and grab the clipboard when it's been selected, then own it again. It doesn't seem to work with Motif though. No biggy, primary works v. well. >I am going to integrate your changes into a future release of xwinclip, but I cannot tell you when that will be. However, a little schedule update: On the other hand, shit happens, so don't expect anything extraordinary. :) Like Chris said it's suprising you can reply at all, and much appreciated. As was suggested I'm going to look at implmenting "a grab the selection only when the windows clipboard has changed" addition to the code. It shouldn't make a great deal of extra code but it will definitely make a minor glitch go bye bye. I'll have a look at integrating it into XWin as well. When more than one XWin window are open it doesn't work properly and if the x windows clients become integrated with windows ala eXceed then it won't work at all. Cheer's, Chris _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
Re: xwinclip - update and motif clipboard
Hi All, As promised an updated version of my xwinclip patch. Major changes: Now ctrl-c works properly, closes nicely, both the windows hook and the x display (and anything else after the event loop). Also a restart works for when the x server crashes/restarts/whatever so will xwinclip. This is done with setjmp and longjmp, so should work within a thread as part of XWin.exe. I've also made all my tab characters two spaces to be in line with Harolds original code and got rid of extra characters on the end of the line (due to NEdit's block operations, handy but I didn't realise they added spaces at the end of lines to the size of the block). There is still lot's of printf's every where for debugging, more so now (due to trying to get the motif clipboard working). Needless to say they don't affect the applications behaviour in XWin. Still outstanding: integration with motif? Not sure it's really worth my effort anymore. Had a go and got nothing more that hassle. It seems to use the motif functions you must only have an Xt app. As xwinclip is xlib alone the two like to cause av's when shoved together. I'm sure I can manage just to highlight text. handling of non windows clipboard change: if the windows clipboard doesn't change don't force the ownership of primary. Should not be much more hassle. Hope all works, let me know. Chris _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com xwinclip_chris_twiner.zip Description: Zip compressed data
Re: xwinclip - update and motif clipboard
>Woohoo! So, when do we get to see the beautiful new code? Hi Brian, I can clean up what I have now, pre motif clipboard and do another post of it to the mailing list. Official release wise is down to Harold. I'll tidy it up tomorrow and send it out. Chris _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
xwinclip - update and motif clipboard
Hi All, Quick update, got the signal working properly for ctrl-c or closing the windows command window. Solution (as the SIGINT handler is run in a seperate thread in windows) is to set a variable in the windows loop that sends the kill message that kill_xwinclip was doing. That means that all the kill_.. apps that I wanted to get rid of can be (and have). It also means that I don't need a window to handle turning on and off clipboard operations a simple close of the window would be sufficient. Also I believe that handling the xIO error as a thread within XWin should be possible but I'd still be tempted to run it seperately as xwinclip. It could work integrated if it was run as a seperate thread (would need to be anyway really), as such longjmp and setjmp should affect only that thread. Again I don't see how much sense this really makes. I do have a remaining issue that I'd like to solve, CLIPBOARD operations. The problem seems to be the application I'm using i.e. NEdit uses Motif programming interfaces (or lesstif) in the default distribution. This leaves four questions : 1) Should we try to get Motif clipboard operations (like klipper)? 2) If so how do we identify that what client owns the clipboard is a motif one (to use the motif mechanism for getting the clipboard data)? 3) Should we try to get motif clipboard before the X clipboard or after? 4) How exactly do we get the motif clipboard? I belive 1) should be a yes but as yet I'm at a loss to attempt the other 3 questions. I have read that the root window property CLIPBOARD holds the clipboard for Motif apps but xprop dumps when i do xprop -root CLIPBOARD. Either way I've have only just started looking at that issue and I'm just about to read http://www.ist.co.uk/motif/books/vol6A/ch-21.fm.html#649570 But any help would be nice from someone who knows the answers now :-) anywho, chris PS (Jehan and Harold, it was all tab characters that I was inserting, I'll change them to the two space's that Harold uses). _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
Re: xwinclip re selection polling
The problem seemed to be based around the old window not getting destroyed, windows still thinks it's there and sends forth more messages to it. I've destroyed the window in the iohandler and the problem seems to be solved. Sorry for the multiple posts just spotted it over a few days. Chris _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: xwinclip re selection polling
Hi All, The select statement isn't the problem, it's the restart. I'm pretty certain that it's just due to the old window sending messages the select does a peekmessage of NULL for the hwnd, this picks up all messages for that thread. The restarter wasn't closing the window so it's probable that the old hwnd for the old window that wasn't getting closed is at fault. This is just a heads up, so no-one starts investigating unnecessarily. I'll post again with the results. Chris _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: xwinclip re selection polling
Hi All, I think I've just identified a bug with select on /dev/windows. According to the select code for the windows device it does a if (peekmessage()) then in xwinclip it does the flushwindows upon select returning. I've found a wierd circumstance were select returns but when the flushwindows function returns there is no message on the queue. As the select believes there is but windows doesn't it causes an infinite loop. Don't know how to reproduce yet but it has been after reconnecting (longjmp and setjmp) that I've noticed. I will investigate more later. I've got a log from the xwinclip output and I'll try to find a reproducable case. Has anyone noticed anything similar before with /dev/windows? Chris _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
Re: xwinclip re selection polling
Hi All, Ok, Harold the jmp is in place (i'm closing the hook and freeing the library first of course) and it works. I needed to change the dll though as it was still using the old HWND for the old cygwin/XFree86 window. If a restart is done off the server menu nothing different seems to happen. It all seems to work fine. Close XWin and it restarts xwinclip (after the freeing of resources), then restart XWin and it reconnects (if it's not out of retries) then all is well in the world. Laters and have a good weekend, Mine is full of a street party outside my door, thankfully they stop playing music at 2am. Chris _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: xwinclip re selection polling
Harold, >Excellent detective work. It looks like longjmp setjmp is the way to go. I will give it a try someday, unless you want to do it first. Thanks, I'll give it a bash. Best place is right at the beginning I think, all the resources will be useless anyway, as they are tied to the old display connection. I've not used setjmp and longjmp before (c++ guy, love those exceptions) so it will be a good thing anyway for me to do them (at least for me:-). >The reason that catching a server reset is so important is that we should not be killed when the server resets and we should try to connect to the server again if it resets. Part of this makes it easy to stay connected when a user is using XDMCP to connect to a remote machine. Also, we can never integrate clipboard support into XWin.exe until we can be assured that the server will not be killed when it resets. That's what I thought the reason was, I'm still not sure that integrating makes that much sense, the jmp solution would seem to solve that but the problem with it is it rewinds the stack right back to the setjmp, that means that whatever else that process has been doing it's screwed. Hence it would have to be forked or spawned anyway. I'll get it restarting anyway, shouldn't take too long. Laters, Chris _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: xwinclip re selection polling
Harold, As an aside this link explains that the only way is to longjmp/setjmp. http://www.faqs.org/faqs/Xt-FAQ/section-19.html If the intention is to fully integrate xwinclip into XWin then this would be unwanted to say the least. Given XWin would close anyway you'd still want xwinclip to close with it. Chris _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: xwinclip re selection polling
>I can't tell if you have enough of an understanding of X11 to write a proposed solution that actually makes sense. At least, I can't make any sense out of your proposal. I understand what he's saying but XLib seems quite against the idea : XSetIOErrorHandler is the first thing and the last thing that happens. Automagically unfortunately so it "can't" be recovered from. What I'm confused about is what does this matter? For me it's a great place to close the hook (stops the hook from not working the next time xwinclip is started). In fact the only thing for me now is to try and get a proper close notification when xwinclip is closed by the user. Ctrl-c doesn't cut it. As an aside it comes back to the Windoze window being visible again (could put a button on it to disable xwinclip's activities, god knows why you'd want to though - as appose to just killing it then resarting it?-). Do you want this information because having a client that is within the x server could cause a big problem when the server disconnects? Personally I think we'd be better off keeping it out of XWin anyway, possibly have it start it but it really is a seperate tool KISS and all that. Why do we need to know when the server is about to close? Chris _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: xwinclip re selection polling
>- 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 y
Re: xwinclip re selection polling
Hi All, It's just going 01.29am here so I won't have a big look at it, but couldn't the windows hook be used for the same purpose i.e. track for the close message. I'll give it a go tomorrow. And yes Jehan, it's just what I need (although I'm about to get a few new hardware toys to play with as well, and who knows work may call me in). laters, Chris _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
Re: xwinclip re selection polling
>There is some obvious cleaning to do here. First, is to use only tabs or >only spaces (don't remember which one Harold uses). Having a mix of space >and tabs is a big mess for people who don't use the same tab size (8 vs 4 >vs 3 vs 2). I'll figure which one's are used and change the stuff accordingly. I thought I had it set, but I didn't check it on another text editor or even cat. >Some files (windproc.c at least) has a huge number of spaces/tabs at then >end of line (see KillXWinclip function ). That's one thing I rarely check for, wouldn't take much either way. >Some files don't have indentation at all (kill_xwinclip.c) or barely >(kill_xclip_hook.c). As you said, there isn't much to them anyway so it's >not a huge task to clean them but that will still help others who would >want to look at the code. Also, even if you want to get rid of them, you >don't know how long they will stay. There was once a guy who said that >storing the date with only 2 digits was be good enough, that by the time we >would get to 2000, the software would have been replaced and corrected... >you know the end of the story ;) Good point, I'll clean them up either way then resubmit. I will have a look at integrating it to XWin anyway. It would be another interesting way to keep my mind active. >I don't know how much of the problems are yours or from the original code >(never looked at it) but it would be a good thing to have that cleaned in >any case. I saw different formating in the files but it could just be the way I've setup NEdit. Again I'll have a crack. >What about trying to integrate xwinclip inside XWin? It would fix this >problem since you don't have to create the Hook. You just have to add a >call to the owner thingie in xwinwndproc.c file. It would also allow to get >rid of the two files you want to remove ;). Last, it would reduce the size >of the Cygwin/XFree to-do list (a killer feature for Harold ;)). As I said I'd be up for that. Just of out interest did you try the changed version? I'm quite interested to know if it works properly on other machines. Thanks for the feedback. Chris _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: xwinclip re selection polling
Hi All, Thanks for the response Harold. I revised the logic in the changes and managed to remove the threading and all that went with it. Guess what, the XWin crashes stopped on both expected exists of xwinclip (via the stopping tool I wrote) and via Ctrl-C/close command. The problem I am trying to solve is that of xwinclip "stealing" the selection ownership from x windows. My main motivation for this is NEdit, the block functions rely on the selection being present and unaltered. Basically all the changes are removal of xsetselectionowners throughout old winclip code and inserting one for primary when Cygwin/XFree86 regains focus. Then adding convertselections to force the insert into the windows clipboard. I've tested it out for XA_PRIMARY don't know any apps that use secondary but I've also tried on CLIPBOARD. It does something but I wouldn't say it works :-). I have attached a zip with the complete files in there, not just diffs etc in case the base version is different now. They xwinclip normal files and the xwinclip_hook file additions have been changed to agree with the sytle guidelines Harold pointed out. kill_xwinclip.c and kill_xwclip_hook.c haven't but there isn't much to them anyway, and I'd like to figure out a way to remove them anyway. I have left the original code in place but commented out where necessary also there are lots of printf's in place to help with debugging. There is shell script called build_dll_extras.SH that builds the dll and the two kill apps. Hope the format is ok. If not tell me and I'll send them back with whatever changes are necessary. Cygwin is a great tool, I want to contribute. Untested and definitely won't work is running more than one screen. The hook relies on the Cygwin/XFree86 window title, it will therefor not work with more than one screen. thanks in advance for the feedback (hopefully positive), Chris Twiner _ Chat with friends online, try MSN Messenger: http://messenger.msn.com xwinclip_chris_twiner.zip Description: Zip compressed data
Re: xwinclip re selection polling
>I think the goal in the not-too-far-away-future is to have xwinclip > >integrated directly inside the XWin app. This would save you the >trouble >to use SetWindowsHookEx, which IIRC is a big piece of crap. >Also, this >would save you the trouble of killing xwinclip while XWin >is still >running. I read that the plan was to integrate it on one of the posts (and the todo list) but the problem would still remain (keeping ownership). You're right though SetWindowsHookEx is awful. It's not too bad for a process only hook but a global is horrible. I think you're right though, wasting more time on the closing down bit would be foolish. When integrated only the setselectionowner's would need to be removed and the two event's code added. Much cleaner but would get rid of the ownership thing. Thanks for the feedback. Nobody replied to the other post so I wondered what interest level there was. Chris _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
xwinclip re selection polling
Hi All, I posted last week that I had a possible solution to the xwinclip selection behaviour. I didn't get any feedback so I endeavoured to do it anyway. So this ones a bit long but it's an explanation of how I've got it working .. Basic premise : Use a seperate dll that runs a system wide Windoze hook to catch all activate messages. 2 events are of interest in the hook, when Cygwin/XFree86 is activated and when it is deactivated. When an event is detected the hook then sends a broadcast registered message to all top level windows. The top level Windoze window for xwinclip is run in a seperate thread and as such always receives the messages. Upon receipt of the activation messages flags are set up that indicate that either xtowindows be called or windowstox. These functions copy the data in the respective directions. The flags have to be used so the main thread (the owner of pDisplay) is the one that calls the functions. They in turn either XSetSelectionOwner (windowstox) or they XConvertSelection (xtowindows) to set the messages running. Major changes are that the select in xwinclip.c has a time limit applied and that the XSetSelectionOwner in xevents.c and XSetSelectionOwner in xwinclip.c are removed. This means that all selection operations behave as expected in XWin with xwinclip running. However I have some limitations: closing xwinclip: closing XWin closes xwinclip but doesn't go through WM_DESTROY on the x window, just XIO: fatal IO error 113 (Connection aborted) on X server "127.0.0.1:0.0" after 48 requests (47 known processed) with 0 events remaining. I made a script to close xwinclip via sending an X message but it results in crashing XWin as well. the select statement timeout: In order to get the polling on the notification flags (from the windows thread) the timer is set to 1 sec (or some other time). Is there a way to make the flags act as file descriptors for the select statement? Any help on the problems would be appreciated. The code is still (cough cough) a little rough n ready so I will release it when appropriate. Is putting a zip attachment on this mailing list appropriate? I have only been working on this for 3 days and it's my first attempt at X antics so if these are FAQ style items I appologise (I've looked just can't find them). Regards, Chris Twiner _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
xwinclip re selection polling
Hi All, I'm a first time poster so appologies if I've misunderstood the etiquette rules or not found a previous answer to this. The message at : http://sources.redhat.com/ml/cygwin-xfree/2002-01/msg00213.html Lists polling as an unsatisfactory way of handling the ownership setting issue. Whilst I agree I do have a slight variation to question on. If a windows hook were used i.e. SetWindowsHookEx would this not tell you when the XWin looses focus. Would this not be a good time to claim ownership of selection and ask for it's content. The reverse would also be true that you could use the time when XWin gains focus to handle the setting ownership of PRIMARY and CLIPBOARD to hold the windows clipboard data. Again excuse the ignorance if this isn't helpful in anyway. I only started looking at xwinclip 3 days ago and I'd never seen X development before that. Hope it is helpful, Chris Twiner _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
