[Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?

[Kevin Walzer]

Bill Janssen wrote:
> has <hengist.podd at virgin.net> wrote:
> 
>> Annoying, but tweaking
>> the Python.app bundle's LSBackgroundOnly/LSUIElement flags isn't a
>> solution, it's a kludge - one that will take us back to the bad old
>> days where some scripts automatically fail when run with 'python'.
> 
> *Right now*, some scripts fail when run with "python".  My scripts :-).
> 
> Look, setting LSUIElement still allows access to the WM -- that's what
> it's for:
> 
> ``LSUIElement (String). If this key is set to '1', Launch Services runs
> the application as an agent application. Agent applications do not
> appear in the Dock or in the Force Quit window. Although they typically
> run as background applications, they can come to the foreground to
> present a user interface if desired. A click on a window belonging to an
> agent application brings that application forward to handle events.''
> 
> I'm *only* suggesting this for Python.app -- other Python-based apps,
> like IDLE.app, that desire a dock icon can still have a different
> Info.plist.
> 
> For that matter, even if we set LSBackgroundOnly, you'd still have
> access to the WM -- my appscript-based "while True" loop runs fine when
> I set this flag.
> 
> The key is that you can always make the process more "heavyweight", but
> you can't go in the other direction.  So Python should start as low as
> possible, and work up as necessary.
> 
> Bill

I've been following this proposed change with some interest. My gut is 
telling me a strong "no" on it.

My development is of GUI apps, and I like being able to double-click on 
a Python script and have it do the Right Thing--that is, launch as a 
foreground GUI process in Tkinter. Having to run py2app to test my apps 
would be a rather large pain. Having to remember to run "pythonw" 
instead of "python" if I'm testing in Terminal would be nearly as much 
pain. (PythonLauncher was broken in 2.5.x, at least for a couple of 
iterations, and I'm pleased it's working again in 2.6.)

Bill, the behavior that you experiencing is the expected behavior of 
Python, albeit not what you want in this instance. Rather than re-doing 
the long-standing infractucture of Python on the Mac, wouldn't it be 
better to find the code that is causing the undesired "rocket launch" 
and fix it, or at least work around it? Woudn't a non-framework, 
Unix-style build of Python avoid these issues altogether?

--Kevin


-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com