That IS brain-crushingly complicated. However, thanks for the insight. I really appreciate it.
Dennis Lee Bieber wrote: > On 17 Jul 2006 21:00:09 -0700, "dfaber" <[EMAIL PROTECTED]> declaimed > the following in comp.lang.python: > > > Is there no clean method of accessing the keyboard device or the mouse > > on linux? > > It seems that looking at /proc/interrupts might prove to be useful for > > keyboard monitoring. What about checking if the left mouse button is > > clicked or finding the position of the cursor on the screen? > > For a GUI application, it probably depends upon the interface > supplied by that GUI system... So far as I know, all Linux variants are > using an X-Window clone as the bottom protocol. > > Problem: X-Window supports remote displays; you'd need a means of > specifying which display to track (unless you've opened a GUI > application and that application is asking for positions -- but it may > not be able to track outside the application window... Sorry to be so > vague -- I last coded an X interface back in 1990, using xt/DECWindows > calls; didn't even have a GUI designer available*) > > I don't think anyone has ported raw X-protocol access to Python. > > All those "monitoring" operations you are asking for are "events" to > a windowing environment, and applications have to "register" for the > events they are interested in seeing. > > > > * If working raw xt/DECWindows wasn't bad enough... Add GKS (is that > still around?) on top of it -- I had a DECWindows UI whose main window > was a plain drawing region, and GKS was used to handle the underlying > data. The application was both graphics intensive, and needed a display > list (in scaleable coordinates to handle window resize) for refresh > operations; it used a 32 color "data" field, and four or so single color > "overlays" -- and any one of the five could be enabled/disabled without > requiring a recomputation of the drawing. This mess was because the > DECWindows/GKS application was an emulation (at the API level) of a late > 70s/early 80s RAMTEK graphics engine... The "main" application was > really something like 50 specialized programs that all "connected" to > the "graphics engine", drew some data, and exited; allowing other > programs in the suite to draw on the /same/ window -- which is why the > need for GKS; refreshes couldn't ask for the source application to > repaint the screen. {The very oldest version of the software ran on > PDP-11s, hence the modular programs, the control program would collect > user data/parameters, write a "common block file" then invoke the needed > submodule as an overlay. > -- > Wulfraed Dennis Lee Bieber KD6MOG > [EMAIL PROTECTED] [EMAIL PROTECTED] > HTTP://wlfraed.home.netcom.com/ > (Bestiaria Support Staff: [EMAIL PROTECTED]) > HTTP://www.bestiaria.com/ -- http://mail.python.org/mailman/listinfo/python-list