Track keyboard and mouse usage

[dfaber]

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" <deusfaber at gmail.com> 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
> 	wlfraed at ix.netcom.com		wulfraed at bestiaria.com
> 		HTTP://wlfraed.home.netcom.com/
> 	(Bestiaria Support Staff:		web-asst at bestiaria.com)
> 		HTTP://www.bestiaria.com/