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] MacPython sprint at PyCon'09?
Ronald Oussoren wrote: I'm going to Pycon this year and I'm wondering if anyone is interested in doing a MacPython related sprint afterwards. There is about a 50% chance that I'll be going. Possible topics: * Investigate OSX-integration issues (such as the rocket icon that sometimes appears) yes, though I know nothing about it! * Get Py2app development going again Absolutely! really key! * Packaging 3th-party extensions (especially those using non-system C libraries) for OSX. That is, how to do the package collection on pythonmac.org correctly. also good, though it seems the desire for a package collection has dwindled -- or is the community just waiting for some leadership to get it going again? * PyObjC not my thing -- but good stuff. -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
[Pythonmac-SIG] MacPython sprint at PyCon'09?
Hi, I'm going to Pycon this year and I'm wondering if anyone is interested in doing a MacPython related sprint afterwards. Possible topics: * Investigate OSX-integration issues (such as the rocket icon that sometimes appears) * Get Py2app development going again * Packaging 3th-party extensions (especially those using non-system C libraries) for OSX. That is, how to do the package collection on pythonmac.org correctly. * PyObjC Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] setting LSUIElement in Python.app Info.plist
I have to say, I find the somewhat uninformed resistance to this idea incredible. It's an *idea*, folks, not a patch. It can't hit OS X in any form till 10.7, which is well over a year away. Relax -- try it out, read the docs, and report back. Let's *find out* what the effects of doing this would be, not speculate about them. 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] wx Window Flashes and Closes Immediately
Robin Dunn wrote: I thought Robin said that this default was going to be changed, so that newbies would have this issue less -- what happened to that? I didn't think it would be a good idea to change a default like this between two 2.8.x releases, but it's already changed in the 2.9 source tree. Sounds like the right call -- thanks! -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] Py2app -- where is canonical repository, what version is current?
On 14 Jan, 2009, at 2:47, s s wrote: I've been trying to figure out where the _real_ current Py2app is. AFAIK this is the current home: http://svn.pythonmac.org/py2app/py2app/trunk I really need to add some things (compiling xib - nib, for example) to build my project and I'd prefer to start with something to which I could actually contribute my changes. Patches for that would be greatly appricated. Feel free to send patches to me, I have commit access to the repository. 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 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
[Pythonmac-SIG] py2app with matplotlib
I've searched around and found some mentions of problems when building apps
with matplotlib, but didn't see any definitive solutions.
I'm trying to build a simple using matplotlib, numpy and wx. My setup.py
looks like this:
from setuptools import setup
APP = ['plot_in_wx_test.py']
DATA_FILES = ['IMV_0.log']
OPTIONS = {
'argv_emulation': True,
'packages': ['matplotlib', 'numpy']
}
setup(
app=APP,
data_files=DATA_FILES,
options={'py2app': OPTIONS},
setup_requires=['py2app'],
)
# EOF
When I do:
bri...@omaha$ ls -F
dist/plot_in_wx_test.app/Contents/Resources/lib/python2.5/
config@matplotlib/site-packages.zip
lib-dynload/ numpy/ site.py@
Yet, when I try to run
./dist/wx_mpl_dynamic_graph.app/Contents/MacOS/wx_mpl_dynamic_graph I get an
import errorthe application appears to know nothing about any type of
matplotlib:
File
./dist/wx_mpl_dynamic_graph.app/Contents/Resources/wx_mpl_dynamic_graph.py,
line 31, in module
import matplotlib
ImportError: No module named matplotlib
Am I doing something wrong or is this a known issue?
BZ
___
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
Re: [Pythonmac-SIG] py2app with matplotlib
On Mon, Feb 2, 2009 at 11:00 PM, Brian Zambrano bri...@gmail.com wrote: When I do: bri...@omaha$ ls -F dist/plot_in_wx_test.app/Contents/Resources/lib/python2.5/ config@matplotlib/site-packages.zip lib-dynload/ numpy/ site.py@ Yet, when I try to run ./dist/wx_mpl_dynamic_graph.app/Contents/MacOS/wx_mpl_dynamic_graph I get an import errorthe application appears to know nothing about any type of matplotlib: File ./dist/wx_mpl_dynamic_graph.app/Contents/Resources/wx_mpl_dynamic_graph.py, line 31, in module import matplotlib ImportError: No module named matplotlib After some hunting and digging I solved this. After upgrading Python 2.5.1 which comes in OS X 10.5 to Python 2.5.4, all is well. I found this out in a roundabout wayfirst I got it working after realizing the path was off when the App fired up. The libraries were ending up in dist/plot_in_wx_test.app/Contents/Resources/lib/python2.5/ which wasn't in sys.path. What *was* in sys.path was: dist/plot_in_wx_test.app/Contents/Resources/lib/python2.5/site-packages After a little hackery I got it working. Then I realized that Python wasn't being included in the build so upgraded to 2.5.4 (which wasn't as simple as I hoped). After that, the build worked no problem. Hopefully this will be useful to someone else. BZ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
