Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: Can you reproduce the issue in the second problem with a simple script? If so, please file a bug in the python bugtracker and assign it to me. If I could, I'd be halfway to fixing it -- but thanks! The dock icon should mean you're calling an API that requires access to the window server. Does the daemon program work when you start it without begin logged on to the console (that is, log in using an SSH session without being logged on on the console)? If that doesn't work, it shouldn't work either with and without the LSUIElement key. Right. But it also means that there are more things than appscript which can cause this. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 5 Feb, 2009, at 17:04, Bill Janssen wrote: Ronald Oussoren ronaldousso...@mac.com wrote: The dock icon should mean you're calling an API that requires access to the window server. Does the daemon program work when you start it without begin logged on to the console (that is, log in using an SSH session without being logged on on the console)? If that doesn't work, it shouldn't work either with and without the LSUIElement key. Right. But it also means that there are more things than appscript which can cause this. Of course, there are various API's that cause this effect and appscript is not the only user of those APIs. To rephrase my question: can you start the daemon program without being logged on to the console and check if it works at all (both with and without the LSUIElement being set)? That's something I cannot test with appscript because that can't work without being logged on to the console as it needs to access other running applications to work. Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: LSUIElement=1 completely surpresses the dock icon and menu bar for an application, although you can get those back by calling an API. This would be a support nightmare for python.app, any (OSX) newby that runs a Tkinter script from a tutorial ends up with a non-functional application. Whether we need to also upgrade the tutorials strikes me as a minor matter. Furthermore cross-platform scripts would have to call the upgrade-API to ensure they have a menu, making OSX different from Linux and Windows. No, as you then point out... Both could be worked around by including a call to the upgrade-API in the startup code for GUI toolkits (Tkinter, WxWidget, QT, ...), but that would mean you can no longer create agent applications using those toolkits. Yeah, we'd want to a call in the toolkit to make to enable that, which modifies the level that the automatic upgrade upgrades to. An agent application is supposed to be a mostly faceless background application that can pop-up a window when it needs to. I guess Growl would be a good example of such functionality, although I haven't checked if they use the LSUIElement key. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 4 Feb, 2009, at 18:50, Bill Janssen wrote: Ronald Oussoren ronaldousso...@mac.com wrote: LSUIElement=1 completely surpresses the dock icon and menu bar for an application, although you can get those back by calling an API. This would be a support nightmare for python.app, any (OSX) newby that runs a Tkinter script from a tutorial ends up with a non-functional application. Whether we need to also upgrade the tutorials strikes me as a minor matter. You'd have to modify every tutorial out there, including books. That's not really feaseable. The right ways to fix the issue you're running into with appscript are 1) Wrap your script into an .app bundle that includes the LSUIElement setting (because appeartly you are writing an application that is an agent-style application) 2) Research why appscript causes the icon to appear on the dock. As has noted it should be possible to avoid that because the ScriptingBridge framework doesn't have this problem. The second option would be the most useful for the community, but is way harder than the first option. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren wrote: I've tested the LSUIElement key with a GUI script, and based on that I'm opposed to including that key in Python.app. You can always wrap your scripts in an app bundle that does have the key set, or investigate how to avoid getting the rocket icon in the dock when you use appscript, as Has suggested. [...] Agreed. Today's MacPython is, or should be, a superset of standard *nix Python. OS X is *nix at the shell level, and tools that work on other *nixes ought to work the same on OS X, otherwise you end up in a situation where users have to maintain two separate Python installations for compatibility. Users won't like that; neither, I suspect, would Apple. Bill's problem is with appscript; that's where the fix should be as well. I don't have time to work on it, but y'all are welcome to grab the latest trunk and hack on it. Regards, 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
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 3 Feb, 2009, at 19:00, Bill Janssen wrote: Chris, I'm a bit confused, too. Could someone (Bill?) summarize what functionally will change if this change is applied? Basically, if you're running /usr/bin/python or Python.app directly, you still won't get a dock icon even if you're using appscript. The app is marked as an agent application -- still trying to figure out just what that means. That means you won't get a menu bar either. agent application seems to mean an application that is usually completely hidden but needs to pop up GUI items (such as windows) sometimes. Agent applications don't have a dock item, and don't have a menu bar either. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 3 Feb, 2009, at 19:14, Bill Janssen wrote: But in the spirit of education, here's what I've got in my Python.app's Info.plist: keyLSUIElement/key true/ That's the wrong definition, it should be: keyLSUIElement/key string1/string See http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/20001431-108256 , or /System/Library/CoreServices/Dock.app/Contents/Info.plist. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 4 Feb, 2009, at 1:14, Christopher Barker wrote: Kevin Walzer wrote: 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. I think it's clear that lot's of us want that. the question is, will the proposal break that? One option is that the GUI toolkits run the code to promote themselves to a full GUI app. In which case, I think you're above scenario would work. OF course, ALL the gui toolkits would have to add that code, but if they did, would that meet your needs? If GUI toolkits automaticly promote themselves to full GUI apps you can no longer create an agent-style application in Python. Or at least not without introducing another API that disables the promotion, said API would be non-standard and therefore not easily findable. I haven't read the recent history of this list to find the thread that triggered this thread, but from the bits I have read it seems that there is one major reason for wanting this feature: when you use appscript from a non-gui script you might end up with a rocket icon in your dock because appscript calls an API that promotes the application to GUI status. Adding the LSUIElement key to the Info.plist file is basically a workaround for an unwanted (and probably avoidable) feature caused by some Carbon call(s) in the appscript implementation. The way to fix that issue is not to add LSUIElement to the Info.plist, but to look for a way to avoid calling the API(s) that cause the promotion to full GUI status. I will look at appscript, but not before Pycon. Ronald -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: Whether we need to also upgrade the tutorials strikes me as a minor matter. You'd have to modify every tutorial out there, including books. That's not really feaseable. Python changes. Tutorials need to keep changing. The right ways to fix the issue you're running into with appscript are 1) Wrap your script into an .app bundle that includes the LSUIElement setting (because appeartly you are writing an application that is an agent-style application) 2) Research why appscript causes the icon to appear on the dock. As has noted it should be possible to avoid that because the ScriptingBridge framework doesn't have this problem. The second option would be the most useful for the community, but is way harder than the first option. Yes, both of those are good ideas. But it's not just appscript; I'm doing something else in a different program (that doesn't use appscript) that also causes the rocket-in-the-dock problem. This one is particularly irritating, because it's a real daemon, and can't always get through to the dock. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 4 Feb, 2009, at 23:26, Bill Janssen wrote: The right ways to fix the issue you're running into with appscript are 1) Wrap your script into an .app bundle that includes the LSUIElement setting (because appeartly you are writing an application that is an agent-style application) 2) Research why appscript causes the icon to appear on the dock. As has noted it should be possible to avoid that because the ScriptingBridge framework doesn't have this problem. The second option would be the most useful for the community, but is way harder than the first option. Yes, both of those are good ideas. But it's not just appscript; I'm doing something else in a different program (that doesn't use appscript) that also causes the rocket-in-the-dock problem. This one is particularly irritating, because it's a real daemon, and can't always get through to the dock. Can you reproduce the issue in the second problem with a simple script? If so, please file a bug in the python bugtracker and assign it to me. The dock icon should mean you're calling an API that requires access to the window server. Does the daemon program work when you start it without begin logged on to the console (that is, log in using an SSH session without being logged on on the console)? If that doesn't work, it shouldn't work either with and without the LSUIElement key. Ronald Bill smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Am 2009-02-03 um 03:47 schrieb Bill Janssen: I'd suggest that promotion to LSUIElement (agent application) by the toolkit is probably right, but I'd suggest that you only promote to full app by actually having an app bundle that overrides the default Info.plist. Sorry for chirping in as a non-expert... If I understood you right, then any GUI app would behave different as app bundle or standalone. That would make the development of GUI apps unnecessary complicated (it takes a while to compile an app bundle, and they're rather heavy). Most of *my* wxPython-based (actually dabo-based) tools don't even need to be an app bundle - doubleclicking some .py file is mostly enough. But I wouldn't like to loose some GUI functionality. Greetlings from Lake Constance! Hraban --- http://www.fiee.net https://www.cacert.org (I'm an assurer) ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 2 Feb, 2009, at 19:27, Bill Janssen wrote: Christopher Barker chris.bar...@noaa.gov wrote: Bill Janssen wrote: It seems to me that this is what we want for the Python interpreter proper. could be. It sounds promising. Applications (like IDLE) that are indeed proper foreground apps can always call TransformProcessType() to override this setting and get a dock icon for themselves. Could you change it in the info.plist of a py2app'ed app also? Id suggest that that be default in py2app. You kind of need to use py2app (or similar) to get an app to act right in the GUI anyway. Yes, that sounds like a good idea to me. I've never used py2app; does it include a private copy of Python? The application bundles that py2app builds don't use Python.app, but can include a copy of relevant parts of the Python.framework. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 2 Feb, 2009, at 21:53, Bill Janssen wrote: In any case, it does include a info.plist, and it may include a different launch stub, so setting LSUIElement = 1 may work in either case. Sounds reasonable, then. Set LSUIElement=1 in the Python.app Info.plist, and other apps that use python can set it differently if they wish. Does this actually solve the problem you want to fix? Have you looked into what causes the icon to occur into the doc in the first place? What are possible side effects of setting this property? I'm definitly -1 on changes this flag before Python 2.7 and 3.1, and before these questions are answered. If the flag gets added the reason for it needs to be documented, to avoid it getting ripped out later on. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
IDLE.app goes to some lengths to convince OS X that it is executing under its own app bundle even though it is running the interpreter from the framework Python.app executable (more execve trickery) so the Python.app Info.plist settings don't apply. BTW, IDLE.app is also broken in 3.x but I think I have that all sorted out now. It should be fixed in the 3.1 branch. I've spent about half a day to fix issues in IDLE because some helpful sole had applied fixes that broke idle unless you installed newer version of the Tcl/Tk framework. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 2 Feb, 2009, at 17:58, Bill Janssen wrote: I'm thinking that the right thing to do about rocket-in-the-dock should be to change the Info.plist of Python.app, to include the setting LSUIElement: 1. Here's the doc from Apple: ``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.The Dock and loginwindow are two applications that run as agent applications.'' It seems to me that this is what we want for the Python interpreter proper. Applications (like IDLE) that are indeed proper foreground apps can always call TransformProcessType() to override this setting and get a dock icon for themselves. I don't agree. Python.app is as it is to make it possible to run simple GUI scripts from the command-line, if I understand the LSUIElement document correctly the setting you propose would make it impossible to use python sometkscript.py to run a simple GUI script. IMHO the best way to get rid of the Rocket icon is to investigate what causes the icon to appear and to look for workarounds for that. The icon should only occur when the application (e.g. python script) communicates with the window server. Ronald Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill Janssen wrote: Chris, if you followed the thread, you'll know that what's happening is that the Python.app app is being promoted to a full app, without any provision for behaving like a full app. In particular, it doesn't participate in the various shutdown handshakes, and thus prevents logout or shutdown. This is pernicious. No more pernicious than a similarly written AppleScript applet. If a Python script needs to respond to external desktop-level events, it should create its own event loop and drive its main logic off that event loop. 'while 1: do_everything()' just doesn't cut it in any event-driven environment. As for automatically promoting scripts that require Window Manager access, the current behaviour is the correct one. It is more important that a script should succeed than be elegant. Elegance is nice to have, but irrelevant if the thing won't even launch. This is why the old python/pythonw distinction was done away with: the default choice (python) ensured that some scripts would fail. Now all scripts succeed. The problem as it relates to py-appscript is that py-appscript doesn't need WM access, but the OS promotes it anyway as a side-effect of calling certain Carbon APIs from within a .app bundle. The script ought to run as a regular *nix process, responding to standard *nix signals as needed, but the OS frustrates that. 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'. The correct solution would be for Apple to make their APIs more selective about upgrading the process when it doesn't need to be, but I doubt it's something that's important to them so don't hold your breath. The alternative is for Python to provide a 'pythonb' (where 'b' stands for 'background') alternative to the default 'python' interpreter that scripts can use when they know they don't need WM access. And if you eventually want to get to the point of having only a single 'python' interpreter, you could start pushing the Tk, wx, etc. folks to add their own code for upgrading the process at startup, and then do away with the .app bundle in a few more years once you can be confident that you aren't going to break any scripts by doing so. ... The other thing I will suggest is that somebody figures out a patch for appscript that replaces the current Process Manager calls with calls of equivalent functionality that do not cause the OS to upgrade the process. I _do_not_ have time to work on this problem myself (I am up to my ears in RL commitments), but I'll be delighted to incorporate any contributed patch that I'm satisfied won't break any of appscript's existing behaviour. It must be doable: Leopard's Scripting Bridge manages to avoid triggering the upgrade process, and I'm assuming (though have not checked) that it also targets processes by pid. Regards, 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
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Henning Hraban Ramm hra...@fiee.net wrote: But I wouldn't like to loose some GUI functionality. I'm sure that's true. But I think the change I'm proposing needn't cause any negative effects. I've lost the ability to log out, and would like that back! Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: if I understand the LSUIElement document correctly the setting you propose would make it impossible to use python sometkscript.py to run a simple GUI script. Then you misunderstand either LSUIElement, or the discussion so far. What we'd like to do is to retain that capability. Please read the Apple document I referenced earlier to get an idea of what the three different classes of application are. In any case, you can always promote an app to a heavier-weight presence; what Apple doesn't give us an interface for is to demote the app if it's been promoted by accident. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: On 2 Feb, 2009, at 21:53, Bill Janssen wrote: In any case, it does include a info.plist, and it may include a different launch stub, so setting LSUIElement = 1 may work in either case. Sounds reasonable, then. Set LSUIElement=1 in the Python.app Info.plist, and other apps that use python can set it differently if they wish. Does this actually solve the problem you want to fix? Yes. Have you looked into what causes the icon to occur into the doc in the first place? According to Hengist: Perhaps it's not the OS upgrading the process, but rather some code in some extension calling TransformProcessType It's the Carbon Process Manager. (There's no good reason for it to do so, but hey, I didn't write the thing.) Do we have the sources for that, do you know? What are possible side effects of setting this property? See the Apple doc I referenced earlier. I'm going to set this flag (LSUIElement) in the system Python of every Mac at PARC I can get my hands on, so we'll get some idea of the effects. I encourage others on this list to also set it, and see what kind of effects you notice. So far, my experience is positive. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: Most of *my* wxPython-based (actually dabo-based) tools don't even need to be an app bundle - doubleclicking some .py file is mostly enough. But I wouldn't like to loose some GUI functionality. IMHO running the script shouldn't be the default action for .py files, ever. I have two reason's for that: (1) most .py files I run into are just source code instead of scripts and shouldn't be executed but opened in an editor, and (2) this makes it way to easy to accidently execute a random python script that you've downloaded from the internet. Yes, I agree. I'm seriously wondering if having Python Launcher.app is a good idea, and if we shouldn't scrap it entirely. If building full app bundles using py2app is too much of a burden we could look into providing an easier and more lightweight way to build such bundles. The fully standalone bundles that py2app creates are very useful, but I definitely see the need for very thin .app bundles as well. Interesting idea. What's the lightest thing that's an app, anyway? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
has hengist.p...@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 ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 3 Feb, 2009, at 17:54, Bill Janssen wrote: I'm seriously wondering if having Python Launcher.app is a good idea, and if we shouldn't scrap it entirely. If building full app bundles using py2app is too much of a burden we could look into providing an easier and more lightweight way to build such bundles. The fully standalone bundles that py2app creates are very useful, but I definitely see the need for very thin .app bundles as well. Interesting idea. What's the lightest thing that's an app, anyway? AFAIK an executable + Info.plist + icon file (plus the right directory structure). The executable can be shell-script on Leopard, but a simple executable would IMHO be better. One way to structure such an executable is to read the name of the actual script to execute from the Info.plist (using a custom key) and then use the standard Python C- API to execute that script. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
First: I've read this thread, I've read the Apple docs (at least one level deep -- I really don't get this stuff, and I don't have the time to learn it all!) I still don't get what LSUIElement is supposed to do, and what functionality will change if it's set. I did try setting it on my system, and saw no difference whatsoever in my quick tests with wx. Could someone (Bill?) summarize what functionally will change if this change is applied? I'm a bit concerned (as expressed by others) that while focusing on one use case, that other, very common, usages could be effected. For that matter, I don't really understand the use case that you're trying to address. Here's my guess -- please correct me: Some python scripts that are GUI-free are calling some Carbon APIs that cause the system to promote them to full-GUI mode, and that then breaks things: - you get a icon in the doc, which you don't want - they are not shut down by the system when logging off/shutting down, 'cause they don't respond to the appropriate calls. By the way, that later issues confuses the heck out of me -- why the heck would anyone write a system shut down procedure that couldn't override a non-responsive application? -- weird. (of course, Windows does it too...) Anyway, it's hard for us to comment on the proposal if we don't' understand the issues, and since you are proposing it, the burden is on you to educate us -- sorry. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill Janssen wrote: Ronald Oussoren ronaldousso...@mac.com wrote: The fully standalone bundles that py2app creates are very useful, but I definitely see the need for very thin .app bundles as well. Interesting idea. What's the lightest thing that's an app, anyway? You can run py2app in Alias mode ($python setup.py py2app -A), and you get a full app bundle that has links to everything it needs, rather than actually including it all. They are faster to build, but the main advantage is that as the code changes, you don't have to do anything, the bundle is referencing the original copy anyway. It still acts as a full application. As an example, I use this to run the Peppy editor (nice editor -- you should all take a look at it!). I've got the Alias bundle set up, I put it in the dock and just use it like a .app -- click on it to start, drag and drop files on it, etc. when I do an svn up, I get the updated version, and don't have to touch a thing. I'm sure alias bundles have their limitations (aside from the obvious one of only working on that machine, with all its python packages), but I'm not sure what they are beyond the same limitations of running a script directly. They build faster and more reliably that full py2app bundles, too. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill, Thanks for making the effort to understand and explain all this. Many of us remember the many why won't this work! posts to the mailing list so we just want to be careful. Some concerns: ``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. This is a concern -- what if I do need to Force Quit my app? I can probably find it with ps, and kill it with kill, but that's only because I was a Linux geek before I got a Mac. Also, if you do want an icon in the dock -- even the default rocket -- you would need to do something special to get it, no? Though: I've tried changing my info.plist and haven't seen any change at all -- how do I know if I did it right? I'm *only* suggesting this for Python.app -- That's not an ONLY -- that's how most python code is run. IDLE.app is an exception -- that's the point here, it sounds like you are trying to make things work better for non-gui, background-ish apps, but neglecting GUI development. Sure, once I've got my big app written and bundled up with py2app, I can set the info.plist the way I want (and py2app can do the right thing by default.), but I have a LOT of little wx scripts that I want to work when started from the command line. In short: I should be able start this script from the command line: import wx A = wx.App() F = wx.Frame(None) F.Show() And get a dock icon, and have it show up in Force Quit, and be able to do everything else GUI it would usually do. 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 Which does make sense. As there are really only a few GUI toolkits: wxPython TkInter pyObjC pyQT It may be fine to have the GUI code promote the app, but we do need to get those devs on board (as Robin apparently already is). And another option is the pythonb option for background apps, analogous to the old pythonw -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Henning Hraban Ramm wrote: Most of *my* wxPython-based (actually dabo-based) tools don't even need to be an app bundle - doubleclicking some .py file is mostly enough. Check out py2app -A. It's perfect for this kind of use. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote:
On 3 Feb, 2009, at 17:54, Bill Janssen wrote:
I'm seriously wondering if having Python Launcher.app is a good
idea, and if we shouldn't scrap it entirely. If building full app
bundles using py2app is too much of a burden we could look into
providing an easier and more lightweight way to build such bundles.
The fully standalone bundles that py2app creates are very useful, but
I definitely see the need for very thin .app bundles as well.
Interesting idea. What's the lightest thing that's an app, anyway?
AFAIK an executable + Info.plist + icon file (plus the right directory
structure). The executable can be shell-script on Leopard, but a
simple executable would IMHO be better. One way to structure such an
executable is to read the name of the actual script to execute from
the Info.plist (using a custom key) and then use the standard Python
C-
API to execute that script.
So you'd have a little custom launcher that would read that key and use
the Python C API -- sort of the way that Java apps use the
JavaApplicationStub. Doesn't actually have to be a C program, you know;
it could be a shell script:
#!/usr/bin/python
import plistlib, os
script =
os.path.normpath(plistlib.readPlist('../Info.plist')['ApplicationPythonScript'])
os.execv(['/usr/bin/python', script])
I didn't test that!
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Chris, I'm a bit confused, too. Could someone (Bill?) summarize what functionally will change if this change is applied? Basically, if you're running /usr/bin/python or Python.app directly, you still won't get a dock icon even if you're using appscript. The app is marked as an agent application -- still trying to figure out just what that means. Some python scripts that are GUI-free are calling some Carbon APIs that cause the system to promote them to full-GUI mode, and that then breaks things: - you get a icon in the doc, which you don't want - they are not shut down by the system when logging off/shutting down, 'cause they don't respond to the appropriate calls. Yep, that's what seems to be happening. By the way, that later issues confuses the heck out of me -- why the heck would anyone write a system shut down procedure that couldn't override a non-responsive application? -- weird. (of course, Windows does it too...) Excellent point. I think what happens is that the system thinks Python should be responding to it, and when it doesn't (because it's been improperly promoted), it feels it might have timed out, and to avoid losing your data, cancels the logout. I assume there's some magic key combo you could press while logging out to override that protection; I just don't know what it is. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Christopher Barker chris.bar...@noaa.gov wrote: This is a concern -- what if I do need to Force Quit my app? I can probably find it with ps, and kill it with kill, but that's only because I was a Linux geek before I got a Mac. Then give your app its own Info.plist. There are zillions of processes running on your Mac that don't appear in the Force Quit window -- that's what Activity Monitor is for. Also, if you do want an icon in the dock -- even the default rocket -- you would need to do something special to get it, no? Yes -- use a different Info.plist. Though: I've tried changing my info.plist and haven't seen any change at all -- how do I know if I did it right? I'm tempted to say: if you don't know whether or not you've done it right, don't try doing it at all. But in the spirit of education, here's what I've got in my Python.app's Info.plist: keyLSUIElement/key true/ 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 Which does make sense. Thanks! As there are really only a few GUI toolkits: wxPython TkInter pyObjC pyQT It may be fine to have the GUI code promote the app, but we do need to get those devs on board (as Robin apparently already is). Sure. TkInter is part of Python, so any patch should cover that as well. PyObjC programs can make the call directly, if they wish to, but most PyObjC programs with windows are probably full-fledged apps, anyway. Don't know much about pyQt, or pyGTK. I also don't think the GUI toolkit should promote willy-nilly -- it should probably provide a call which the user program can make to promote. And another option is the pythonb option for background apps, analogous to the old pythonw Or PythonBackground.app, which would also be a way to slice this. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 3 Feb, 2009, at 9:10, Henning Hraban Ramm wrote: Most of *my* wxPython-based (actually dabo-based) tools don't even need to be an app bundle - doubleclicking some .py file is mostly enough. But I wouldn't like to loose some GUI functionality. IMHO running the script shouldn't be the default action for .py files, ever. I have two reason's for that: (1) most .py files I run into are just source code instead of scripts and shouldn't be executed but opened in an editor, and (2) this makes it way to easy to accidently execute a random python script that you've downloaded from the internet. I'm seriously wondering if having Python Launcher.app is a good idea, and if we shouldn't scrap it entirely. If building full app bundles using py2app is too much of a burden we could look into providing an easier and more lightweight way to build such bundles. The fully standalone bundles that py2app creates are very useful, but I definitely see the need for very thin .app bundles as well. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 3 Feb, 2009, at 18:55, Bill Janssen wrote:
Ronald Oussoren ronaldousso...@mac.com wrote:
On 3 Feb, 2009, at 17:54, Bill Janssen wrote:
I'm seriously wondering if having Python Launcher.app is a good
idea, and if we shouldn't scrap it entirely. If building full app
bundles using py2app is too much of a burden we could look into
providing an easier and more lightweight way to build such bundles.
The fully standalone bundles that py2app creates are very useful,
but
I definitely see the need for very thin .app bundles as well.
Interesting idea. What's the lightest thing that's an app, anyway?
AFAIK an executable + Info.plist + icon file (plus the right
directory
structure). The executable can be shell-script on Leopard, but a
simple executable would IMHO be better. One way to structure such an
executable is to read the name of the actual script to execute from
the Info.plist (using a custom key) and then use the standard Python
C-
API to execute that script.
So you'd have a little custom launcher that would read that key and
use
the Python C API -- sort of the way that Java apps use the
JavaApplicationStub. Doesn't actually have to be a C program, you
know;
it could be a shell script:
#!/usr/bin/python
import plistlib, os
script = os.path.normpath(plistlib.readPlist('../Info.plist')
['ApplicationPythonScript'])
os.execv(['/usr/bin/python', script])
I didn't test that!
Not quite, you must ensure that the C-level argv[0] points to a
location inside the app bundle, otherwise the system won't know you're
supposed to be an executable. Getting that right is possible (just
copy the python executable into the bundle as well), but just writing
a small stub executable is not too hard and avoids issues like http://bugs.python.org/issue5143
.
Ronald
Bill
smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill Janssen wrote: has hengist.p...@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 ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Kevin Walzer k...@codebykevin.com wrote: 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? It would, and that's actually the long-standing infrastructure of Python on the Mac that you refer to. The Python.app formulation is recent, and not yet well-enough debugged. Try setting LSUIElement in your Python.app's Info.plist, and report back with what's broken. I think you'll find double-clicking on UI apps works just fine. Though I also think that launching by double-clicking on .py files is a mistaken binding. It should probably bring up an editor. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill Janssen jans...@parc.com wrote: It would, and that's actually the long-standing infrastructure of Python on the Mac that you refer to. The Python.app formulation is recent, and not yet well-enough debugged. Though, I should hasten to say, I think removing the distinction between python and pythonw was a decided improvement. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
On 3 Feb, 2009, at 17:49, Bill Janssen wrote: Ronald Oussoren ronaldousso...@mac.com wrote: if I understand the LSUIElement document correctly the setting you propose would make it impossible to use python sometkscript.py to run a simple GUI script. Then you misunderstand either LSUIElement, or the discussion so far. What we'd like to do is to retain that capability. I've tested the LSUIElement key with a GUI script, and based on that I'm opposed to including that key in Python.app. You can always wrap your scripts in an app bundle that does have the key set, or investigate how to avoid getting the rocket icon in the dock when you use appscript, as Has suggested. LSUIElement=1 completely surpresses the dock icon and menu bar for an application, although you can get those back by calling an API. This would be a support nightmare for python.app, any (OSX) newby that runs a Tkinter script from a tutorial ends up with a non-functional application. Furthermore cross-platform scripts would have to call the upgrade-API to ensure they have a menu, making OSX different from Linux and Windows. Both could be worked around by including a call to the upgrade-API in the startup code for GUI toolkits (Tkinter, WxWidget, QT, ...), but that would mean you can no longer create agent applications using those toolkits. An agent application is supposed to be a mostly faceless background application that can pop-up a window when it needs to. I guess Growl would be a good example of such functionality, although I haven't checked if they use the LSUIElement key. Ronald Please read the Apple document I referenced earlier to get an idea of what the three different classes of application are. In any case, you can always promote an app to a heavier-weight presence; what Apple doesn't give us an interface for is to demote the app if it's been promoted by accident. Bill smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
I'm thinking that the right thing to do about rocket-in-the-dock should be to change the Info.plist of Python.app, to include the setting LSUIElement: 1. Here's the doc from Apple: ``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.The Dock and loginwindow are two applications that run as agent applications.'' It seems to me that this is what we want for the Python interpreter proper. Applications (like IDLE) that are indeed proper foreground apps can always call TransformProcessType() to override this setting and get a dock icon for themselves. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill Janssen wrote: It seems to me that this is what we want for the Python interpreter proper. could be. It sounds promising. Applications (like IDLE) that are indeed proper foreground apps can always call TransformProcessType() to override this setting and get a dock icon for themselves. Could you change it in the info.plist of a py2app'ed app also? Id suggest that that be default in py2app. You kind of need to use py2app (or similar) to get an app to act right in the GUI anyway. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Christopher Barker chris.bar...@noaa.gov wrote: Bill Janssen wrote: It seems to me that this is what we want for the Python interpreter proper. could be. It sounds promising. Applications (like IDLE) that are indeed proper foreground apps can always call TransformProcessType() to override this setting and get a dock icon for themselves. Could you change it in the info.plist of a py2app'ed app also? Id suggest that that be default in py2app. You kind of need to use py2app (or similar) to get an app to act right in the GUI anyway. Yes, that sounds like a good idea to me. I've never used py2app; does it include a private copy of Python? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill Janssen wrote: Yes, that sounds like a good idea to me. I've never used py2app; does it include a private copy of Python? yes and no: yes, if you run it with the non-apple python no, if you run it with Apple's system python (which I think is next to useless, frankly -- Apple does not keep the system python consistent between versions) In any case, it does include a info.plist, and it may include a different launch stub, so setting LSUIElement = 1 may work in either case. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Christopher Barker chris.bar...@noaa.gov wrote: Bill Janssen wrote: Yes, that sounds like a good idea to me. I've never used py2app; does it include a private copy of Python? yes and no: yes, if you run it with the non-apple python no, if you run it with Apple's system python (which I think is next to useless, frankly -- Apple does not keep the system python consistent between versions) In any case, it does include a info.plist, and it may include a different launch stub, so setting LSUIElement = 1 may work in either case. Sounds reasonable, then. Set LSUIElement=1 in the Python.app Info.plist, and other apps that use python can set it differently if they wish. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In article 73365.1233593...@parc.com, Bill Janssen jans...@parc.com wrote: I'm thinking that the right thing to do about rocket-in-the-dock should be to change the Info.plist of Python.app, to include the setting LSUIElement: 1. There's also LSBackgroundOnly. That might be even more appropriate. But OTOH ... It seems to me that this is what we want for the Python interpreter proper. Applications (like IDLE) that are indeed proper foreground apps can always call TransformProcessType() to override this setting and get a dock icon for themselves. ... setting it does have the side effect of making IDLE's menus disappear when launched from the command line (bin/idle). (Launching via IDLE.app is unaffected.) It also has the effect of removing the default Tcl/Tk-supplied menu bar for Tkinter programs; try running the turtleDemo, for instance. Those programs lose Copy/Paste/Cut and the Quit, though the app does quit if you click the red window close button. Perhaps tkinter can call TPT. I'm poking in that area at the moment and will be submitting a number of patches for 3.x and 2.x real soon now. I'll try to whip something up in the next few days and report back. One thing the background settings doesn't seem to change is the regression test (subprocess) that brings up the Application Failed dialog. But I haven't had time to look at that one in detail yet. Have you tried this with appscript? -- Ned Deily, n...@acm.org ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ned Deily n...@acm.org wrote: In article 73365.1233593...@parc.com, Bill Janssen jans...@parc.com wrote: I'm thinking that the right thing to do about rocket-in-the-dock should be to change the Info.plist of Python.app, to include the setting LSUIElement: 1. There's also LSBackgroundOnly. That might be even more appropriate. But OTOH ... Yes, I'm thinking that, too. I'm running my system Python with that set, and it seems to fix my various problems. For others following along, here's the pointer to the Apple docs: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html ... setting it does have the side effect of making IDLE's menus disappear when launched from the command line (bin/idle). (Launching via IDLE.app is unaffected.) Fascinating. But I don't think that's fatal -- shouldn't users be using IDLE.app? It also has the effect of removing the default Tcl/Tk-supplied menu bar for Tkinter programs; try running the turtleDemo, for instance. Those programs lose Copy/Paste/Cut and the Quit, though the app does quit if you click the red window close button. Perhaps tkinter can call TPT. Indeed. Given that there's already a #ifdef TK_AQUA section in Modules/_tkinter.c:init_tkinter(), I'd think that would be a fine place to put a call to TransformProcessType. That would probably make IDLE's menus reappear when launched from the command-line, too. I'm poking in that area at the moment and will be submitting a number of patches for 3.x and 2.x real soon now. I'll try to whip something up in the next few days and report back. I'll review them. One thing the background settings doesn't seem to change is the regression test (subprocess) that brings up the Application Failed dialog. But I haven't had time to look at that one in detail yet. Have you tried this with appscript? Yes. My appscript scanning app is working fine with LSBackgroundOnly set, and no rocket in the dock. I can logout, the various Python processes are terminated fine. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In article 77657.1233609...@parc.com, Bill Janssen jans...@parc.com wrote: Ned Deily n...@acm.org wrote: In article 73365.1233593...@parc.com, Bill Janssen jans...@parc.com wrote: I'm thinking that the right thing to do about rocket-in-the-dock should be to change the Info.plist of Python.app, to include the setting LSUIElement: 1. There's also LSBackgroundOnly. That might be even more appropriate. But OTOH ... Yes, I'm thinking that, too. I'm running my system Python with that set, and it seems to fix my various problems. For others following along, here's the pointer to the Apple docs: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Art icles/PListKeys.html ... setting it does have the side effect of making IDLE's menus disappear when launched from the command line (bin/idle). (Launching via IDLE.app is unaffected.) Fascinating. IDLE.app goes to some lengths to convince OS X that it is executing under its own app bundle even though it is running the interpreter from the framework Python.app executable (more execve trickery) so the Python.app Info.plist settings don't apply. BTW, IDLE.app is also broken in 3.x but I think I have that all sorted out now. But I don't think that's fatal -- shouldn't users be using IDLE.app? Either way is supposed to work although there have been some discrepancies in menu behavior that I've sorted out. It also has the effect of removing the default Tcl/Tk-supplied menu bar for Tkinter programs; try running the turtleDemo, for instance. Those programs lose Copy/Paste/Cut and the Quit, though the app does quit if you click the red window close button. Perhaps tkinter can call TPT. Indeed. Given that there's already a #ifdef TK_AQUA section in Modules/_tkinter.c:init_tkinter(), I'd think that would be a fine place to put a call to TransformProcessType. That would probably make IDLE's menus reappear when launched from the command-line, too. Yes.. I'm poking in that area at the moment and will be submitting a number of patches for 3.x and 2.x real soon now. I'll try to whip something up in the next few days and report back. I'll review them. Good. I still have a couple of regressions to understand before I'm ready to submit them. My goal is to be able to more easily produce clean 3.x and 2.x Mac installers. One thing the background settings doesn't seem to change is the regression test (subprocess) that brings up the Application Failed dialog. But I haven't had time to look at that one in detail yet. Have you tried this with appscript? Yes. My appscript scanning app is working fine with LSBackgroundOnly set, and no rocket in the dock. I can logout, the various Python processes are terminated fine. Progress! -- Ned Deily, n...@acm.org ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Christopher Barker chris.bar...@noaa.gov wrote: Ned Deily wrote: I'm thinking that the right thing to do about rocket-in-the-dock should be to change the Info.plist of Python.app, to include the setting LSUIElement: 1. There's also LSBackgroundOnly. That might be even more appropriate. I doubt it -- the whole point of this mess was to allow apps full-on desktop access. Setting LSBackgroundOnly doesn't prevent that, it just sets the default. Maybe we just need to return to the old python vs. pythonw distinction, but with a different default -- have a python-no-gui option. I don't believe we need to. ... setting it does have the side effect of making IDLE's menus disappear when launched from the command line (bin/idle). This is no OK -- it may be OK for IDLE itself, but when people are testing an debugging GUI apps (TK, or wx, or) they should be able to start a simple script at the command line without any restrictions. Sure, open myapp.app. But if you follow the conversation a bit further, I think we've found a place to enable that for _tkinter. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill Janssen wrote: Setting LSBackgroundOnly doesn't prevent that, it just sets the default. I don't understand -- what default? just the behavior when the app starts, but then it can still open windows, etc? when people are testing an debugging GUI apps (TK, or wx, or) they should be able to start a simple script at the command line without any restrictions. Sure, open myapp.app. I meant without an app bundle -- just a raw python script. But if you follow the conversation a bit further, I think we've found a place to enable that for _tkinter. Does it require a change to _tkinter? If so, then all the GUI toolkits (OK, all three...) would have to be changed for this to work, which doesn't sound good. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill Janssen wrote: But only tkinter is part of the Python distribution, I believe. Of course, whoever supports the various non-standard GUI toolkits might also want to make changes, if necessary. Of course, that's a pretty standard thing that most third-party packages have to do when a new version of Python is released, so I don't think it's a big deal. I have no problem adding a call to TransformProcessType (or whatever will be needed) to wxPython's startup code. I think it's safe to assume that if wx is being imported then the process should be promoted to a full desktop app. Since this requirement will appear in some specific version of Python it will be easy to make the API call be conditionally compiled. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Robin Dunn ro...@alldunn.com wrote: Bill Janssen wrote: But only tkinter is part of the Python distribution, I believe. Of course, whoever supports the various non-standard GUI toolkits might also want to make changes, if necessary. Of course, that's a pretty standard thing that most third-party packages have to do when a new version of Python is released, so I don't think it's a big deal. I have no problem adding a call to TransformProcessType (or whatever will be needed) to wxPython's startup code. I think it's safe to assume that if wx is being imported then the process should be promoted to a full desktop app. Not really -- that's why Apple has these three classes of application. I'd suggest that promotion to LSUIElement (agent application) by the toolkit is probably right, but I'd suggest that you only promote to full app by actually having an app bundle that overrides the default Info.plist. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
