Paul Boddie wrote:
> [EMAIL PROTECTED] wrote:
> > Sorry, I should have mentioned that I'm running Linux, and I only will
> > be running this app while X is running.
>
> Global "hot keys" are typically the domain of the desktop environment
> (or window manager for archaic desktops).
Yep, that's why my first thought was to use PyQT or PyGTK.
Unfortunately neither seems to have the ability.
> So programmatically setting hot keys may be something that requires
> communication with the desktop environment, and it would appear that on
> KDE you have to put hot key definitions in a file and then import them,
> the latter possibly being achieved using the DCOP interprocess
> communications mechanism provided in the environment (try "dcop
> khotkeys khotkeys" at the shell).
This is really annoying to setup and would be a KDE specific solution.
Ideally this would work under Gnome or KDE. Applications do this all
the time -- Amarok for example adds global shortcuts for playing,
pausing, jumping to next track, etc. that work whether or not you're in
KDE or Gnome.
> I suppose you could just plug in at the X level and have something
> define and intercept a hot key before the desktop environment has a
> chance to process it, but I doubt that this would be a particularly
> nice solution.
Why not? If I had to guess at this point I'd say it's the 'right' way
to do it. I'm going to be dealing with keypresses that no other apps or
the desktop environments have bound to anything, so I'm not sure it
really qualifies as 'intercepting'. If multiple apps have registered to
receive global keypresses, and the first app that looks at a keypress
doesn't know how to handle it, shouldn't it just get passed on to the
next app?
--
http://mail.python.org/mailman/listinfo/python-list
