Bill Janssen wrote:
I'm having a bit of a problem with a Python script I'm running. It
sits
in a loop and periodically asks "System Events" what's going on, via
appscript. The use of appscript turns it into a "foreground process",
Yes, this is annoying and unnecessary behaviour; the problem is that
the OS will automatically GUI-ify any non-GUI process launched from an
application bundle if it calls certain system APIs. Appscript uses the
Process Manager to locate applications and get their process ids, and
unfortunately that's one of the APIs that has this side effect.
This isn't a problem for Ruby appscript as the 'ruby' interpreter
isn't packaged as a .app, but the 'python' executables in
Python.framework's bin directory all use the framework's Python.app
executable to run the script; hence the automatic promotion when it
uses Process Manager.
Slightly embarrassing for me, as I was one of those pushing for the
previous python/pythonw distinction to be eliminated, which it was in
Python 2.4, but I didn't realise at the time that this would have
negative as well as positive consequences for appscript. I still think
allowing the 'python' executable to automatically promote itself was a
reasonable thing to do, as it's the one that folk habitually use and
prior to 2.4 this would catch them out when running a script that
required GUI access, e.g. to display a dialog.
What might be useful if there was also a 'pythonb' executable that
doesn't provide automatic promotion for benefit of those who know what
they're doing, although I'm not sure if that falls outside the
responsibility of the main Python distribution.
This means that when I try to logout, or reboot, the loginwindow sends
it a kAEQuitApplication event, but it never replies, which means that
after 45 seconds loginwindow automatically aborts the logout or
shutdown. So, I either need to take that darn rocket out of the Dock
(which I'd like to be able to do),
If you don't want your python process to be promoted, there are a few
tricks you could try: target System Events by PID or raw address
descriptor instead of name/path/bundle id; run your script with a non-
framework Python; copy Python.app's executable (.../Python.app/
Contents/MacOS/Python) to /usr/local/bin/pythonb and use that to run
your scripts.
or somehow catch and handle kAEQuitApplication events.
aemreceive's sfba module lets you run an event loop, which you need to
handle any sort of incoming events, and installs a default 'quit'
handler for you. It doesn't provide support for Carbon timers or
background threads, however, so wouldn't be any use to you here. A
better solution would be to build use Cocoa to provide your script
with an event loop, as PyObjC isn't subject to the same restrictions
as sfba.
HTH
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
