Re: Capturing events from the root window
On Sat, 1 Nov 2003 11:55:08 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: the raise will raise ontop of everything - BUt something may raise itself above your window immediately afterwards too... Bad luck. :) inputonly windows are invisible windows. you can map,unmap, move, resize, get events (mouswe moves, button presses, key events etc.) on them, but they do not visually do anything on the screen. ok, that's what I want. yes. every time a window is created (or destroyed etc. etc.) if you select for the right event mask (structure substructurenotify) x will tell u when the root window and children of it change (created, destoryed, reparent, move, resize, restack etc.) with events. this is close to what a window manager does (close, but not quite). i'd definitely suggets the inputonly window. u will never be ab;e to sensibly pass events on, but in the area of the screen the inputonly window lives, you can eat all the events yourself :) Can I monitor the mousemovment for all windows? Like a grab, but not that I grab the events, just get a notification about an event. Another idea that just occured is to monitor mousemovement and rais my window when the mouse is in the area where I want it to be activated. Can this be done? And how would I do this? Using a grab doesn't work but you guys always talk of polling the root window or monitor it. How can this be done? Polling is only the last ressort of course because it is not nice. :) on-top stacking of your inputonly window) then if the mouse exits that toolbor, hide it again. monitor stacking as mentioned above with structure substructurenotify mask set on root and handle the events. the problemn here is This is similar to what the sidebar can do in Window, but I don't like it. It always gets in the way because it pops up when you don't need it. really gdk/gtk. i dont know how well it will deal with this. if u did it in xlib u'd be fine, but i am not sure if gdk/gtk will be 100% happy. others might know if ti will or will not. If I have one solution either in X or in GTK then I can worry about the other. If I have a GTK solution, thats fine. If I find an Xlib solution then I cann see how to do it in GTK or do some wrapper for this. But first I have to find at least ONE solution that works as I want it to. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Fri, 31 Oct 2003 21:21:15 +, Raymond Jennings [EMAIL PROTECTED] wrote: You could fudge it if you have to. Monitor your window for configure notify events, and poll the root window. Whenever there is information How can I poll the root window? X sends me an XEvent when something happens, at least if I told X to be notified, so I wonder how I can poll on this. But polling is not really what I want to do. If I can find a way to monitor mousemovement, without empeding the other applications like with a grab, then I think I can also live with it. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window (ID20311056 ignore this number)
On Fri, 31 Oct 2003 21:24:46 +, Raymond Jennings [EMAIL PROTECTED] wrote: windows are visible (i.e. the X server will tell you that they exist, where they are, etc), but you can only receive events related to windows that YOU own. I tried now to use that VisibilityNotify event but the problem is that my window doesn't seem to get this event. Carsten said that this might be because this event will not be sent for InputOnly windows, so I don't receive the events I would need. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Fri, 31 Oct 2003 10:52:44 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: no. the wm - or any app can go raising windows above yours... you cant clock windows in place to be on top as such. (ok we can argue of some nasty hacks and methods if you are the wm... but thats a world on its own.) If I raise my window, how can I make sure that it is on top of all? ok. for a normal window yes its possible to get events to know if you got obscured. they are called visibilitynotify events. BUT i am actually not sure if they will be received by inputonly windows. but thats the path you want to go. Whats input only windows? How can I make sure my window is not an InputOnly window but, whatever, else? you could find if a window has been raised/lowered etc. by monitoring creatnotifies on root, then on every windows created monitor structurenotifies then look for configurenotify events and check the stacking sections (above, window, event). again - i dont know how well gdk(gtk) supports this part of x so you may have to dump into xlib. I don'tneccessarily need to do that. If it is possible to make sure that my window is raised on top off all, then I can simply monitor for this visibillitynotify, and raise it anyway. If it is not possible to create other window then this inputwindow then I can monitor this createnotify. How is this working? Does root then send me an event everytime a window is created? hmm how is it meant to work? mouse goes to left or right side of window, launcher buttons pop up and u click one to run something? Yes. The nice thing of this tool is, that it always works. You don't need to have a window or a bar or anything on the screen which you need to access. It's really usefull to have around, thats why I decided to port it to linux. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
You could fudge it if you have to. Monitor your window for configure notify events, and poll the root window. Whenever there is information indicating that your window is no longer at the top, restack it so that it becomes on top if you have to. This will work, but you'll need to keep your latency down. It will take about a split second for it to jump. This ought to work no matter what window manager you use. This is a sure fire kludge, but there might be a better way. Does X11 provide a always on top flag? From: Gerhard W. Gruber [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Capturing events from the root window Date: Thu, 30 Oct 2003 23:07:37 +0100 On Fri, 31 Oct 2003 08:51:07 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: you willonly then get events when the mouse passes over your thin window. That's no problem as long as my window stays on top. not as a widget - no. you'll have to jump down to gdk. i'm not sure if gdk supports this though. you'll want an inputonly window thats a toplevel window (immediate child of root) thats override-redirect. you'll need to also monitor I managed to create an invisible window which is only one pixel in widht and has the same height as the screen (hardcoded for now, how can I query the current resolution?). The only problem, I still have is, to make the window stay on top of all others in order to always receive input events when the user moves the mouse to the right border (or where he configured it). Is it possible to create a window that always stays on top? Not only of it's own application, but of all application windows. If not, is it possible to get an event when my window is obscured or lowered because another window has been raised over it? Actually getting the inof when it is obscored would be enough because it only needs to stay accessible all the time and for this it doesn't have to be the top window. And can I raise a window above all others? I browsed the web for this, but it seems that is also not possible. Everytime I think of a new way how to achieve what I need it seems to be blocked by X. :( all client windows, where they move, go etc. and follow i'm still not even 100% sure what it is you want to actually do (in overall aim) You can take a look in the readme at http://sourceforge.net/projects/launchmenu, there I explain it. Its just a simple app that has been proven quite usefull to me over the years and I wrote this for myself because the original source is not portable and the author doesn't give away all the source anyway. If you don't want to download the package, it is of course in the CVS as well. there's a whole extension devoted to recording events - the xrecord extension - but i know very little about it. :) No prob. It wouldn't do what I need anyway. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _ Enjoy MSN 8 patented spam control and more with MSN 8 Dial-up Internet Service. Try it FREE for one month! http://join.msn.com/?page=dept/dialup ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window (ID20311056 ignore this number)
Unless you own the root window, you probably can't intercept events. The X server knows which connection each window belongs to, and only THAT connection gets events relayed to it. Short of hacking X, there's no way to steal messages. You COULD monitor the stacking order, and listen for interesting events on YOUR window, and periodically (once every 1/10th of a second or so) POLL the status and stacking order of your window. All windows are visible (i.e. the X server will tell you that they exist, where they are, etc), but you can only receive events related to windows that YOU own. From: Gerhard W. Gruber [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Capturing events from the root window Date: Thu, 30 Oct 2003 23:07:37 +0100 On Fri, 31 Oct 2003 08:51:07 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: you willonly then get events when the mouse passes over your thin window. That's no problem as long as my window stays on top. not as a widget - no. you'll have to jump down to gdk. i'm not sure if gdk supports this though. you'll want an inputonly window thats a toplevel window (immediate child of root) thats override-redirect. you'll need to also monitor I managed to create an invisible window which is only one pixel in widht and has the same height as the screen (hardcoded for now, how can I query the current resolution?). The only problem, I still have is, to make the window stay on top of all others in order to always receive input events when the user moves the mouse to the right border (or where he configured it). Is it possible to create a window that always stays on top? Not only of it's own application, but of all application windows. If not, is it possible to get an event when my window is obscured or lowered because another window has been raised over it? Actually getting the inof when it is obscored would be enough because it only needs to stay accessible all the time and for this it doesn't have to be the top window. And can I raise a window above all others? I browsed the web for this, but it seems that is also not possible. Everytime I think of a new way how to achieve what I need it seems to be blocked by X. :( all client windows, where they move, go etc. and follow i'm still not even 100% sure what it is you want to actually do (in overall aim) You can take a look in the readme at http://sourceforge.net/projects/launchmenu, there I explain it. Its just a simple app that has been proven quite usefull to me over the years and I wrote this for myself because the original source is not portable and the author doesn't give away all the source anyway. If you don't want to download the package, it is of course in the CVS as well. there's a whole extension devoted to recording events - the xrecord extension - but i know very little about it. :) No prob. It wouldn't do what I need anyway. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _ See when your friends are online with MSN Messenger 6.0. Download it now FREE! http://msnmessenger-download.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Fri, 31 Oct 2003 22:04:22 +0100 "Gerhard W. Gruber" [EMAIL PROTECTED] (Bbabbled: (B (B On Fri, 31 Oct 2003 10:52:44 +1100, Carsten Haitzler (The Rasterman) (B [EMAIL PROTECTED] wrote: (B (B no. the wm - or any app can go raising windows above yours... you cant clock (B windows in place to be on top as such. (ok we can argue of some nasty hacks (B and methods if you are the wm... but thats a world on its own.) (B (B If I raise my window, how can I make sure that it is on top of all? (B (Bthe raise will raise ontop of everything - BUt something may raise itself above (Byour window immediately afterwards too... (B (B ok. for a normal window yes its possible to get events to know if you got (B obscured. they are called visibilitynotify events. BUT i am actually not sure (B if they will be received by inputonly windows. but thats the path you want to (B go. (B (B Whats input only windows? How can I make sure my window is not an InputOnly (B window but, whatever, else? (B (Binputonly windows are invisible windows. you can map,unmap, move, resize, get (Bevents (mouswe moves, button presses, key events etc.) on them, but they do not (Bvisually do anything on the screen. (B (B you could find if a window has been raised/lowered etc. by monitoring (B creatnotifies on root, then on every windows created monitor (B structurenotifies then look for configurenotify events and check the stacking (B sections (above, window, event). again - i dont know how well gdk(gtk) (B supports this part of x so you may have to dump into xlib. (B (B I don'tneccessarily need to do that. If it is possible to make sure that my (B window is raised on top off all, then I can simply monitor for this (B visibillitynotify, and raise it anyway. If it is not possible to create other (B window then this inputwindow then I can monitor this createnotify. How is this (B working? Does root then send me an event everytime a window is created? (B (Byes. every time a window is created (or destroyed etc. etc.) if you select for (Bthe right event mask (structure substructurenotify) x will tell u when the (Broot window and children of it change (created, destoryed, reparent, move, (Bresize, restack etc.) with events. this is close to what a window manager does (B(close, but not quite). i'd definitely suggets the inputonly window. u will (Bnever be ab;e to sensibly pass events on, but in the area of the screen the (Binputonly window lives, you can "eat" all the events yourself :) (B (B hmm how is it meant to work? mouse goes to left or right side of window, (B launcher buttons pop up and u click one to run something? (B (B Yes. The nice thing of this tool is, that it always works. You don't need to (B have a window or a bar or anything on the screen which you need to access. (B (Bhmm - in which case here is what i'd recommend. you use an inputonly window - (Bstick in a corner, edge etc. where u want the "activate" area of the screen (B(that activates the toolbar), then pop up the toolbar (so its raised on TOP of (Byour input only window - have this as an exception in general to maintaining the (Bon-top stacking of your inputonly window) then if the mouse exits that toolbor, (Bhide it again. monitor stacking as mentioned above with structure (Bsubstructurenotify mask set on root and handle the events. the problemn here is (Breally gdk/gtk. i dont know how well it will deal with this. if u did it in xlib (Bu'd be fine, but i am not sure if gdk/gtk will be 100% happy. others might know (Bif ti will or will not. (B (B It's really usefull to have around, thats why I decided to port it to linux. (B (B -- (B Gerhard Gruber (B (B F_r jedes menschliche Problem gibt es immer eine einfache L_sung: (B Klar, einleuchtend und falsch. (Henry Louis Mencken) (B (B ___ (B Devel mailing list (B [EMAIL PROTECTED] (B http://XFree86.Org/mailman/listinfo/devel (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Thu, 30 Oct 2003 08:20:52 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: basically you are competing with the wm. you need to basically hack/modify/patch and work WITH the wm to do what you want. you cant do it on your own. now your solution will be wm specific. So it this means I have to use another way. :) Creating a undecorated invisble window which always stays on top and is only one pixel in width will be possible? This way I can align it the the border the user chooses and then I will get the events for sure. I suppose this should work independent of the WM, right? Do you by chance know how to create such a window as a GtkWidget? If not, no problem, I hope I can find some samples for this on the web. Thanks for your explanation though. I wonder why such a thing never has been implemented. From what I saw brwosing the web I'm not the only one who could use this for some desktop tools. Also I wonder how event recorder will do their job under X? Or is there nos such application for X? Tools similar to WinRunner which capture all events and play them back later. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Thu, 30 Oct 2003, Gerhard W. Gruber wrote: Thanks for your explanation though. I wonder why such a thing never has been implemented. From what I saw brwosing the web I'm not the only one who could use this for some desktop tools. Also I wonder how event recorder will do their job under X? Or is there nos such application for X? Tools similar to WinRunner which capture all events and play them back later. I believe that the RECORD extension is what people use for that sort of thing. xc/doc/hardcopy/Xext/record.PS.gz xc/doc/hardcopy/Xext/recordlib.PS.gz xc/doc/specs/Xext/record.ms xc/doc/specs/Xext/recordlib.ms Don't know whether it will help you at all. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Thu, 2003-10-30 at 20:18, Dr Andrew C Aitchison wrote: On Thu, 30 Oct 2003, Gerhard W. Gruber wrote: Thanks for your explanation though. I wonder why such a thing never has been implemented. From what I saw brwosing the web I'm not the only one who could use this for some desktop tools. Also I wonder how event recorder will do their job under X? Xnee uses RECORD extension to do recording. Have a look at http://www.gnu.org/software/xnee/ Xnee replays as well, using the XTest extension. Or is there nos such application for X? Tools similar to WinRunner which capture all events and play them back later. Don't know anything about WinRunner! Anyway, xnee (as said) does record and replay. /hesa ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Thu, 30 Oct 2003 19:18:31 + (GMT), Dr Andrew C Aitchison [EMAIL PROTECTED] wrote: I believe that the RECORD extension is what people use for that sort of Recording is not really what I need for my app, because I will only see the events and can not prevent them from getting through to other apps. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Fri, 31 Oct 2003 08:51:07 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: you willonly then get events when the mouse passes over your thin window. That's no problem as long as my window stays on top. not as a widget - no. you'll have to jump down to gdk. i'm not sure if gdk supports this though. you'll want an inputonly window thats a toplevel window (immediate child of root) thats override-redirect. you'll need to also monitor I managed to create an invisible window which is only one pixel in widht and has the same height as the screen (hardcoded for now, how can I query the current resolution?). The only problem, I still have is, to make the window stay on top of all others in order to always receive input events when the user moves the mouse to the right border (or where he configured it). Is it possible to create a window that always stays on top? Not only of it's own application, but of all application windows. If not, is it possible to get an event when my window is obscured or lowered because another window has been raised over it? Actually getting the inof when it is obscored would be enough because it only needs to stay accessible all the time and for this it doesn't have to be the top window. And can I raise a window above all others? I browsed the web for this, but it seems that is also not possible. Everytime I think of a new way how to achieve what I need it seems to be blocked by X. :( all client windows, where they move, go etc. and follow i'm still not even 100% sure what it is you want to actually do (in overall aim) You can take a look in the readme at http://sourceforge.net/projects/launchmenu, there I explain it. Its just a simple app that has been proven quite usefull to me over the years and I wrote this for myself because the original source is not portable and the author doesn't give away all the source anyway. If you don't want to download the package, it is of course in the CVS as well. there's a whole extension devoted to recording events - the xrecord extension - but i know very little about it. :) No prob. It wouldn't do what I need anyway. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Thu, 30 Oct 2003 23:07:37 +0100 "Gerhard W. Gruber" [EMAIL PROTECTED] (Bbabbled: (B (B On Fri, 31 Oct 2003 08:51:07 +1100, Carsten Haitzler (The Rasterman) (B [EMAIL PROTECTED] wrote: (B (B you willonly then get events when the mouse passes over your thin window. (B (B That's no problem as long as my window stays on top. (B (Baaah thats a problem. (B (B not as a widget - no. you'll have to jump down to gdk. i'm not sure if gdk (B supports this though. you'll want an inputonly window thats a toplevel window (B (immediate child of root) thats override-redirect. you'll need to also (B monitor (B (B I managed to create an invisible window which is only one pixel in widht and (B has the same height as the screen (hardcoded for now, how can I query the (B current resolution?). The only problem, I still have is, to make the window (B stay on top of all others in order to always receive input events when the (B user moves the mouse to the right border (or where he configured it). (B (Bnot as easy as it sounds too :) (B (B Is it possible to create a window that always stays on top? Not only of it's (B own application, but of all application windows. (B (Bno. the wm - or any app can go raising windows above yours... you cant clock (Bwindows in place to be on top as such. (ok we can argue of some nasty hacks and (Bmethods if you are the wm... but thats a world on its own.) (B (B If not, is it possible to get an event when my window is obscured or lowered (B because another window has been raised over it? Actually getting the inof when (B it is obscored would be enough because it only needs to stay accessible all (B the time and for this it doesn't have to be the top window. And can I raise a (B window above all others? I browsed the web for this, but it seems that is also (B not possible. Everytime I think of a new way how to achieve what I need it (B seems to be blocked by X. :( (B (Bok. for a normal window yes its possible to get events to know if you got (Bobscured. they are called visibilitynotify events. BUT i am actually not sure if (Bthey will be received by inputonly windows. but thats the path you want to go. (Byou could find if a window has been raised/lowered etc. by monitoring (Bcreatnotifies on root, then on every windows created monitor structurenotifies (Bthen look for configurenotify events and check the stacking sections (above, (Bwindow, event). again - i dont know how well gdk(gtk) supports this part of x so (Byou may have to dump into xlib. (B (B (B all client windows, where they move, go etc. and follow i'm still not (B even 100% sure what it is you want to actually do (in overall aim) (B (B You can take a look in the readme at (B http://sourceforge.net/projects/launchmenu, there I explain it. Its just a (B simple app that has been proven quite usefull to me over the years and I wrote (B this for myself because the original source is not portable and the author (B doesn't give away all the source anyway. (B If you don't want to download the package, it is of course in the CVS as well. (B (Bhmm how is it meant to work? mouse goes to left or right side of window, (Blauncher buttons pop up and u click one to run something? (B (B there's a whole extension devoted to recording events - the xrecord extension (B - but i know very little about it. :) (B (B No prob. It wouldn't do what I need anyway. (B (B -- (B Gerhard Gruber (B (B Klar, einleuchtend und falsch. (Henry Louis Mencken) (B (B ___ (B Devel mailing list (B [EMAIL PROTECTED] (B http://XFree86.Org/mailman/listinfo/devel (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Wed, 29 Oct 2003 08:20:00 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: again - see my other reply. you've found a can of worms that basically x doesn't do. ou COULD do this with mouse button presses (XGrabButton) and the dot he XAllowEvent thing... but not just the mouse moving in general. you'd hit a I don't need the mouse movements. I just need the buttons. I read something today about XAllowEvents and I had the impression that this could do what I wanted, but I can't put my finger on it, because I don't know enough about Xlib. limitation of x. you'd HAVE to extend X itself with an extension to do what you are after (unless there is an extension of this i don't know of somewhere. i know xtest wont do it for sure...) Well, xtest is only a small program to test how I can achieve this. I never claimed it would do this and it also isn't finished. It just that, a testprogram so that I don't have to deal with a fullblown application and GTK and wxWindows also. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Wed, 29 Oct 2003 08:17:30 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: this has issues all of its own. first. other peoples windows need to get the correct event at the correct location and time - which now won't be right as windows may have been destroyed, created, shown and hidden, moved and resized, I don't see a problem with this. 1) Why is the timing so critical? The delay should be very small because I just check the event type and would pass it right back on. And 2) even if the timing is wrong, what's the deal? I capture all the events and pass it back (If I manage to find out how this can be done), so the timing is delayed for a, more or less, constant factor. It's not as if my application is real time ciritical, its just a small desktop helper tool. X always has to deal with events not sent to the proper window because of destruction or other things. to re-construct the event to send. your chances of getting this correct are getting slimmer by the second, ESPECIALLY since X is an synchronous environment, I sure don't want to write something like a windowmanager just to support my app. :) also since you have the mouse grabbed to your window (unless you use a big input-only window on top of everything... another can of worms on its own), this I don't have a window and I don't want a proxy window. I would like to use the desktop root window. i can probably find more holes to poke in it all - but suffice to say however you look at it you'll NEVER get it right. your only choice to find out what the mouse is doing outside windows you're listening for events on is to poll. you cannot intercept and optionally not send an event. Suppose I would poll for it then there would still be two questions: 1) How can I poll for this? 2) What do I do if a find that my criteria is met. The requirement is that in that case I should suppress the original message and do my own processing. How can I achieve this? It wouldn't do to scan for Mousebuttonpress and then display the menu and the original app also displays it's context menu. This would be ugly and confusing for the user. this is actually one of x's downfalls which should be fixed. the ability to monitor events globally/in general without having to specifically select on them on target windows. then add the ability to allow/disallow them to go to the next guy listening (first in first served ala the wm?). Yes. That's what the MS Windows Hook mechanism do. There are also limitations, but I managed to work around this to get the tool working mostly as I want it to, though it can use some improvements, but for now I'm content until I can get the linux version working as well. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Wed, 29 Oct 2003 21:13:33 +0100 "Gerhard W. Gruber" [EMAIL PROTECTED] (Bbabbled: (B (B On Wed, 29 Oct 2003 08:20:00 +1100, Carsten Haitzler (The Rasterman) (B [EMAIL PROTECTED] wrote: (B (B again - see my other reply. you've found a can of worms that basically x (B doesn't do. ou COULD do this with mouse button presses (XGrabButton) and the (B dot he XAllowEvent thing... but not just the mouse moving in general. you'd (B hit a (B (B I don't need the mouse movements. I just need the buttons. I read something (B today about XAllowEvents and I had the impression that this could do what I (B wanted, but I can't put my finger on it, because I don't know enough about (B Xlib. (B (Bactually ignore my XGrabButton thing. i forgot that by trying this you'll (Bdisable any wm being able to do click to focus :( you basically are stuck. x (Bcan't do what you want. but just so you know, XAllowEvents is used in (Bcombination with XGrabButton (or XGrabKey). When you passively grab a button or (Bkey on a window, when that button or key (+ modifiers) is pressed, the client (Bthat grabbed gets the event, not the destination window. you cna now process, do (Bsomething (ie for the wm this would be used to do click to focus - ie focus the (Bwindow if it isnt focused). then you can use XAllowEvents to have that event (B"fall through" to its originally intended destination. caveta. if you read any (Bother events from the queue before calling x allowevent you can no longer allow (Bthe event through (imho a real let-down in xlib). BUt again - this is not useful (Bto you as the wm will have grabbed on window frames to do click to focus and (Bthus ancestors of root will have grabs and thus your XGrabButton will fail to (Bactually grab anything. (B (B limitation of x. you'd HAVE to extend X itself with an extension to do what (B you are after (unless there is an extension of this i don't know of (B somewhere. i know xtest wont do it for sure...) (B (B Well, xtest is only a small program to test how I can achieve this. I never (B claimed it would do this and it also isn't finished. It just that, a (B testprogram so that I don't have to deal with a fullblown application and GTK (B and wxWindows also. (B (Bi meant XTest extension (you can fake events with this - with limitations). (B (B (B -- (B Gerhard Gruber (B (B Klar, einleuchtend und falsch. (Henry Louis Mencken) (B (B ___ (B Devel mailing list (B [EMAIL PROTECTED] (B http://XFree86.Org/mailman/listinfo/devel (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Wed, 29 Oct 2003 21:21:16 +0100 "Gerhard W. Gruber" [EMAIL PROTECTED] (Bbabbled: (B (B On Wed, 29 Oct 2003 08:17:30 +1100, Carsten Haitzler (The Rasterman) (B [EMAIL PROTECTED] wrote: (B (B this has issues all of its own. first. other peoples windows need to get the (B correct event at the correct location and time - which now won't be right as (B windows may have been destroyed, created, shown and hidden, moved and (B resized, (B (B I don't see a problem with this. 1) Why is the timing so critical? The delay (B should be very small because I just check the event type and would pass it (B (Bx is asynchronous. let me take an extreme example. i get an event - now i wait 1 (Bsecond then send something along. in that 1 second the window the event happened (Bin could have been closed, moves, destroyed, resized etc. this then changes all (Bthe conditions we had. (B (B right back on. And 2) even if the timing is wrong, what's the deal? I capture (B all the events and pass it back (If I manage to find out how this can be (B done), so the timing is delayed for a, more or less, constant factor. It's not (B as if my application is real time ciritical, its just a small desktop helper (B tool. X always has to deal with events not sent to the proper window because (B of destruction or other things. (B (Bthe timing is important in 2 ways. the way above as i mentioned AND 2. that you (Bset the time member of the event correctly because many apps use that for (Binterpreting double clicks, "quick click" as opposed to "click and drag" for (Bmenu popping up etc. (B (B to re-construct the event to send. your chances of getting this correct are (B getting slimmer by the second, ESPECIALLY since X is an synchronous (B environment, (B (B I sure don't want to write something like a windowmanager just to support my (B app. :) (B (BBUT what you are doing is the domain of window managers. its low level x (Bfiddling and almost everything you do comes with a caveat, exception and (Bproblem. you cant control your environment as well as an app can control things (Bwithin their own windows. (B (B also since you have the mouse grabbed to your window (unless you use a big (B input-only window on top of everything... another can of worms on its own), (B this (B (B I don't have a window and I don't want a proxy window. I would like to use the (B desktop root window. (B (BXGrabButton then - BUT as i said in my other e-mail. this wont work as (Bclick-to-focus will get broken (for starters) not to mention alt+left click (Bdragging etc. (if your wm does it). you're playing games at competing with the (Bwm here - and since the wm is likely run first and going to be pretty stubborn (Babout "winning" you're fighting an uphill battle where the only result will be (Bbroken behavior to the user, and neither you nor the wm will work properly. (B (B i can probably find more holes to poke in it all - but suffice to say however (B you look at it you'll NEVER get it right. your only choice to find out what (B the mouse is doing outside windows you're listening for events on is to poll. (B you cannot intercept and optionally not send an event. (B (B Suppose I would poll for it then there would still be two questions: (B (B 1) How can I poll for this? (B (BXQyeryPointer (B (B 2) What do I do if a find that my criteria is met. The requirement is that in (B that case I should suppress the original message and do my own processing. How (B can I achieve this? (B (Byou cant suppress the original event. now without XGrabButton/XGrabKey - and as (Bi said before - that wont work. (B (B It wouldn't do to scan for Mousebuttonpress and then display the menu and the (B original app also displays it's context menu. This would be ugly and confusing (B for the user. (B (Bbasically you are competing with the wm. you need to basically hack/modify/patch (Band work WITH the wm to do what you want. you cant do it on your own. now your (Bsolution will be wm specific. (B (B this is actually one of x's downfalls which should be fixed. the ability to (B "monitor" events globally/in general without having to specifically select on (B them on target windows. then add the ability to allow/disallow them to go to (B the next guy listening (first in first served ala the wm?). (B (B Yes. That's what the MS Windows Hook mechanism do. There are also limitations, (B but I managed to work around this to get the tool working mostly as I want it (B to, though it can use some improvements, but for now I'm content until I can (B get the linux version working as well. (B (B -- (B Gerhard Gruber (B (B Klar, einleuchtend und falsch. (Henry Louis Mencken) (B (B ___ (B Devel mailing list (B [EMAIL PROTECTED] (B http://XFree86.Org/mailman/listinfo/devel (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am"
Re: Capturing events from the root window
On Tue, 28 Oct 2003 12:19:49 +0100 (MET) "Gerhard Gruber" [EMAIL PROTECTED] (Bbabbled: (B (B I'm not sure if this is the proper forum for asking such a question, but I (B found nothing so far on the web and so I hope to get some answers at the core (B of X. If this is not the correct forum I would really appreciate it if you (B could point me to where I can ask this question. (B (B I'm developing an application which needs to filter all mouse events even (B when it's window is not active. So I tried to grab the pointer and redirect it (B to my app. This works, but the problem I have is that of course X doesn't (B work as long as my app is active because it gets all events and the other apps (B none. I was looking into the Xlib reference manuals if there is some way to (B forward or return the XEvent to X again so it can be processed the normal way. (B In Windows I do this with a hook function which allows me to specify that an (B event is either passed on, or will be discarded after my hookfunction (B returns. I wonder if there is a similar mechanism for X. I was looking into (B GDK, as this would be my prefered way of doing it, but I would settle for a (B Xlib solution as well if there is no other way. (B So what I need is either a way to simply filter events and block them on (B request (prefered) or grab all the input and forward it to the original owner (B if I'm not interested in it. (B (Bbasically there is no choice. you can't do this. you need to POLL for the mouse (Bposition in a timer to do what you want. you dont have the choice of swallowing (Bor allowing a mouse move event (outside your window). (B (Bso you need to poll in a timer. you can then just query the mouse position on (Bthe screen and do what you need to. this does mean a round trip per query and (Bwont make for the nicest app on the planet. (B (Balthough i can think of an evil hack to avoid polling... very evil. so evil i (Bwont mention it. (B (B Can this be done with X and/or GDK/GTK? If I know how to do it in X I could (B probably figure out how to do it in GDK/GTK as well, but I've been searching (B the web for several days now and I couldn't find anything helpfull. There (B seem to be many workarounds for similar problems but none that works for me, (B though. (B (B Thanks for your help. (B (B ___ (B Devel mailing list (B [EMAIL PROTECTED] (B http://XFree86.Org/mailman/listinfo/devel (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
I dont think you will need to poll ... I definittly don't want to poll. That's the ugliest solution that I can think of. :) Also polling doesn't solve the problem of capturing the event as I want it. If I want to take the event for myself then the app shouildn't get it. The app should only get it when I decided that I don't need it. If I have to go this way, then I would rather start a seperate thread with it's own XEvent loop, which is much better for performance and doesn't waste time on polling. you say you already manage to grab them , so then you only need to decide to sent them back or not. Yes. I the XLib function XSendEvent is capable to re-generate the uninteressting event`s and sent them I already tried XSendEvent, but it didn't work out as I expected it. But this may be more a problem of me then of the function. :) When I recive the event it will be filled with all the event data. There are some field in it that tells me the window where the event belong, but this will be alwayxs the root window in my case, right? So when I send the event back with XSendEvent then I will receive it promptly because I capture all events. The proper solution would require 1) that I either determine where the event really belongs to or to 2) send it back telling X that I'm not interested in it and it should pass it on to where it belongs after me. Of course 2 would be prefereable. In case of 1 I wonder how to do it. I don't want to re-implement X in that I should decide which window is visible at where the mousepointer is and send it on to that window (I will investigate this though). I also tried to use XPushBackEvent and then disconnected from the server, then made a small delay and reconnected again. This also didn't work out, because the event was lost, though I would have expected that it should have been put back in the X queue. back to where it should belong ... just make sure that you also investigate all the other things of the event so that you can aftwards generate a proper new one .. The problem is - how can I detect where the event originally belonged to? i believe this special hook part is best done in pure Xlib ... maybe aftwards you can generate GTK - events again , but hooking all events should not a GTK thing I implemented a small test app in pure X. I think I can work my way upwards once I have a solution on that level. But it may not even neccessary. I could also live without that and find another way to feed my app with the event that I capture, so I don't think that this will be the problem (I could be wrong on that, though :) ). As long as I don't have even one solution on any level I don't know how to proceed. That's why I though this list would be a good place to ask, because I thought that here should be many people familiar with X. :) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
Gerhard Gruber schrieb: I dont think you will need to poll ... I definittly don't want to poll. That's the ugliest solution that I can think of. :) Also polling doesn't solve the problem of capturing the event as I want it. If I want to take the event for myself then the app shouildn't get it. The app should only get it when I decided that I don't need it. If I have to go this way, then I would rather start a seperate thread with it's own XEvent loop, which is much better for performance and doesn't waste time on polling. you say you already manage to grab them , so then you only need to decide to sent them back or not. Yes. I the XLib function XSendEvent is capable to re-generate the uninteressting event`s and sent them I already tried XSendEvent, but it didn't work out as I expected it. But this may be more a problem of me then of the function. :) When I recive the event it will be filled with all the event data. There are some field in it that tells me the window where the event belong, but this will be alwayxs the root window in my case, right? So when I send the event back with XSendEvent then I will receive it promptly because I capture all events. The proper solution would require 1) that I either determine where the event really belongs to it should work with XSendEvent shoudlnt it ?? the man tells me XSendEvent(*display*, *w*, *propagate*, *event_mask*, *event_send*) Display http://tronche.com/gui/x/xlib/display/opening.html#Display **display*; Window *w*; Bool *propagate*; long *event_mask*; XEvent http://tronche.com/gui/x/xlib/events/structures.html#XEvent **event_send*; where *w* Specifies the window the event is to be sent to, or *PointerWindow*, or *InputFocus * send it back telling X that I'm not interested in it and it should pass it on to where it belongs after me. Of course 2 would be prefereable. In case of 1 I wonder how to do it. I don't want to re-implement X in that I should decide which window is visible at where the mousepointer is and send it on to that window (I will investigate this though). I also tried to use XPushBackEvent and then disconnected from the server, then made a small delay and reconnected again. This also didn't work out, because the event was lost, though I would have expected that it should have been put back in the X queue. back to where it should belong ... just make sure that you also investigate all the other things of the event so that you can aftwards generate a proper new one .. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Tue, 28 Oct 2003 15:53:39 +0100, Robert Woerle [EMAIL PROTECTED]
wrote:
it should work with XSendEvent shoudlnt it ??
I don't know. From what you told me I looked agina in the manuals and it
sounds like it should, but it doesn't.
Below is the code that I use in my small test programm. It grabs the pointer
events andthis works, as I recive all events no matter where I click, but I
played around with all settings of XSendEvent and I found no way where the
desktop resumed normal operation, as it should. My desktop runs at 1600x1200
this is why I have the if x = 1599.
---
#include stdio.h
#include Xlib.h
#include unistd.h
static int *
null_X_error (Display * d, XErrorEvent * e)
{
static int already = 0;
/* The warning is displayed only once */
if (already != 0)
return (NULL);
already = 1;
printf (\n*** Warning ***\n);
printf (Please, verify that there is not another program which grabs the
mouse\n);
return (NULL);
}
int
main (int argc, char *argv[])
{
Display *d;
XEvent e;
char *dn;
long mask;
dn = XDisplayName(NULL);
if(dn == NULL)
printf(Error getting display name\n);
d = XOpenDisplay(dn);
if(d == NULL)
printf(Error!\n);
XAllowEvents(d, AsyncBoth, CurrentTime);
XSelectInput(d, DefaultRootWindow(d), ButtonPressMask | ButtonReleaseMask);
XGrabButton (d, AnyButton, AnyModifier, DefaultRootWindow(d),
False, ButtonPressMask | ButtonReleaseMask,
GrabModeAsync, GrabModeAsync, None, None);
XSetErrorHandler ((XErrorHandler) null_X_error);
while(1)
{
printf(Waiting\n);
XNextEvent(d, e);
printf(Type: %u\n, e.type);
mask = NoEventMask;
switch (e.type)
{
case ButtonPress:
{
if(e.xbutton.x != 1599)
{
printf(ButtonPress: %u %u/%u\n,
e.xbutton.button,
e.xbutton.x, e.xbutton.y);
printf(Display: %08lX Window: %lu Root:
%lu Sub: %lu\n,
e.xbutton.display, e.xbutton.window, e.xbutton.root, e.xbutton.subwindow);
mask = ButtonPressMask;
}
}
break;
case ButtonRelease:
{
if(e.xbutton.x != 1599)
{
printf(ButtonRelease: %u %u/%u\n,
e.xbutton.button,
e.xbutton.x, e.xbutton.y);
printf(Display: %08lX Window: %lu Root:
%lu Sub: %lu\n,
e.xbutton.display, e.xbutton.window, e.xbutton.root, e.xbutton.subwindow);
mask = ButtonReleaseMask;
}
}
break;
}
// if(mask != NoEventMask)
XSendEvent(e.xbutton.display, InputFocus, False, mask, e);
}
return 0;
}
--
Gerhard Gruber
Für jedes menschliche Problem gibt es immer eine einfache Lösung:
Klar, einleuchtend und falsch. (Henry Louis Mencken)
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Tue, 28 Oct 2003 15:45:19 +0100 (MET) "Gerhard Gruber" [EMAIL PROTECTED] (Bbabbled: (B (B I dont think you will need to "poll " ... (B (B I definittly don't want to poll. That's the ugliest solution that I can (B think of. :) Also polling doesn't solve the problem of capturing the event as (B I want it. If I want to take the event for myself then the app shouildn't get (B it. The app should only get it when I decided that I don't need it. If I have (B to go this way, then I would rather start a seperate thread with it's own (B XEvent loop, which is much better for performance and doesn't waste time on (B polling. (B (B you say you already manage to grab them , so then you only need to (B decide to sent them back or not. (B (B Yes. (B (B I the XLib function XSendEvent is capable to re-generate the (B uninteressting event`s and sent them (B (B I already tried XSendEvent, but it didn't work out as I expected it. But (B this may be more a problem of me then of the function. :) When I recive the (B event it will be filled with all the event data. There are some field in it (B that tells me the window where the event belong, but this will be alwayxs the (B root window in my case, right? So when I send the event back with XSendEvent (B then I will receive it promptly because I capture all events. The proper (B solution would require 1) that I either determine where the event really (B belongs to or to 2) send it back telling X that I'm not interested in it and (B it should pass it on to where it belongs after me. (B (B Of course 2 would be prefereable. In case of 1 I wonder how to do it. I (B don't want to re-implement X in that I should decide which window is visible (B at where the mousepointer is and send it on to that window (I will investigate (B this though). I also tried to use XPushBackEvent and then disconnected from (B the server, then made a small delay and reconnected again. This also didn't (B work out, because the event was lost, though I would have expected that it (B should have been put back in the X queue. (B (B back to where it should belong ... just make sure that you also (B investigate all the other things of the event so that you can aftwards (B generate a proper new one .. (B (B The problem is - how can I detect where the event originally belonged to? (B (B i believe this special "hook part " is best done in pure Xlib ... maybe (B aftwards you can generate GTK - events again , but hooking all events (B should not a GTK thing (B (B I implemented a small test app in pure X. I think I can work my way upwards (B once I have a solution on that level. But it may not even neccessary. I could (B also live without that and find another way to feed my app with the event (B that I capture, so I don't think that this will be the problem (I could be (B wrong on that, though :) ). As long as I don't have even one solution on any (B level I don't know how to proceed. That's why I though this list would be a (B good place to ask, because I thought that here should be many people familiar (B with X. :) (B (Bagain - see my other reply. you've found a can of worms that basically x doesn't (Bdo. ou COULD do this with mouse button presses (XGrabButton) and the dot he (BXAllowEvent thing... but not just the mouse moving in general. you'd hit a (Blimitation of x. you'd HAVE to extend X itself with an extension to do what you (Bare after (unless there is an extension of this i don't know of somewhere. i (Bknow xtest wont do it for sure...) (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Tue, 28 Oct 2003 13:13:06 +0100 Robert Woerle [EMAIL PROTECTED] babbled: (B (B Carsten Haitzler (The Rasterman) schrieb: (B (B On Tue, 28 Oct 2003 12:19:49 +0100 (MET) "Gerhard Gruber" [EMAIL PROTECTED] (B babbled: (B (B (B (B I'm not sure if this is the proper forum for asking such a question, but I (B found nothing so far on the web and so I hope to get some answers at the (B coreof X. If this is not the correct forum I would really appreciate it if (B youcould point me to where I can ask this question. (B (B I'm developing an application which needs to filter all mouse events even (B when it's window is not active. So I tried to grab the pointer and redirect (B itto my app. This works, but the problem I have is that of course X doesn't (B work as long as my app is active because it gets all events and the other (B appsnone. I was looking into the Xlib reference manuals if there is some way (B toforward or return the XEvent to X again so it can be processed the normal (B way.In Windows I do this with a hook function which allows me to specify (B that anevent is either passed on, or will be discarded after my hookfunction (B returns. I wonder if there is a similar mechanism for X. I was looking into (B GDK, as this would be my prefered way of doing it, but I would settle for a (B Xlib solution as well if there is no other way. (B So what I need is either a way to simply filter events and block them on (B request (prefered) or grab all the input and forward it to the original (B ownerif I'm not interested in it. (B (B (B (B basically there is no choice. you can't do this. you need to POLL for the (B mouse position in a timer to do what you want. you dont have the choice of (B swallowing or allowing a mouse move event (outside your window). (B (B I dont think you will need to "poll " ... (B you just wait for them to come and then go on . (B (B you say you already manage to grab them , so then you only need to (B decide to sent them back or not. (B I the XLib function XSendEvent is capable to re-generate the (B uninteressting event`s and sent them (B back to where it should belong ... just make sure that you also (B investigate all the other things of the event so that you can aftwards (B generate a proper new one .. (B (Bthis has issues all of its own. first. other peoples windows need to get the (Bcorrect event at the correct location and time - which now won't be right as (Bwindows may have been destroyed, created, shown and hidden, moved and resized, (Braised and lowered, shape mask changed etc. in the meantime. remember you need (Bto keep the list of shape rectangles of the window to determine if the mous is (Binside or outside of it - this may change and you now have to poll every window (Byou think might possibly contain the mouse for its shape mask and rectangles. (Byou need to determine which window the mouse would be in and its offset in order (Bto re-construct the event to send. your chances of getting this correct are (Bgetting slimmer by the second, ESPECIALLY since X is an synchronous environment, (Bby the time you query for things, it all may have changed server-side. you could (Bgrab the server during every query... but now we're talking REALLY stupid code. (B (Balso since you have the mouse grabbed to your window (unless you use a big (Binput-only window on top of everything... another can of worms on its own), this (Balso makes 1. menus not work cause other apps/toolkits will want to grab mice to (Bmenu windows etc. for this, 2. "mouse bindings" of the wm wont work (alt +left (Bmouse anywhere in the window wont move it). 3. to make a vague attempt to keep (Bin sync you'll need to monitor the entire x window tree ALL the time... NOT fun (Bor efficient. Also other apps might even ignore mouse move events with the (B"send_event" flag set to 1. what you have there is a partially working system (Bthat will only work for some things - and will need a LOT of code which will (Bnever be accurate or correct anyway. (B (Bi can probably find more holes to poke in it all - but suffice to say however (Byou look at it you'll NEVER get it right. your only choice to find out what the (Bmouse is doing outside windows you're listening for events on is to poll. you (Bcannot intercept and optionally not send an event. (B (Bthis is actually one of x's downfalls which should be fixed. the ability to (B"monitor" events globally/in general without having to specifically select on (Bthem on target windows. then add the ability to allow/disallow them to go to the (Bnext guy listening (first in first served ala the wm?). (B (B what you then did is to make your own "hook - function" like you where (B used to in windows .. (B (B - i think (B (B (B so you need to poll in a timer. you can then just query the mouse position on (B the screen and do what you need to. this does mean a round trip per query and (B
