Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
Now that there are several people that want to support Apple's build of python: how do we go forward from here? I think we should start a small project for "MacPython Addons", this project will install: * Hotfix for distutils to ensure that distutils builds univeral binaries (32-bit only at first) * (possibly) hotfix to ensure that you can install '-fat-' eggs on 10.5 * /Applications/Python-2.5/IDLE.app In there future we could add other changes, such as a 'python64' command for running python in 64-bit code. IMHO this should be done only when we have patches python.org tree that enable 4-way universal builds on Leopard, otherwise we'd have a real risk of loosing these changes in a future version. Ronald On 2 Jan, 2008, at 21:33, Bill Janssen wrote: Even though I've been an open source developer since long before the word existed I find that I'm getting sick and tired of the reinvent- the-world attitude that is far too common in the open source community. If I am new to Python on the Mac and I've played with Apple Python a little, but as soon as I want to install one little add-on module I have to first replace the whole existing Python with something new (and not directly Apple-endorsed) I might just drop out. And at the very least it's mightily inconvenient. Well said, Jack! I think supporting/fixing the Apple-supplied Python should be a goal. I certainly used the Tiger 'Apple' Python for everything, living with its various foibles, and I intend to do the same with Leopard. I can see why cutting edge developers might want to have other versions installed (I've got 2.6 and 3.0 on my Leopard machine, for instance), but all my normal software is developed against /usr/bin/python. Bill smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
Hi All, I'm not sure whether this is the correct thread/place for this, but is there any official "best practice" for Python under Leopard? I.E., should we still be using the MacPython framework build (since I assume that is more likely to track current python versions than the Apple build). Is this on the main python or macpython websites somewhere? Thanks, Andrew Ronald Oussoren wrote: > Now that there are several people that want to support Apple's build of > python: how do we go forward from here? > > I think we should start a small project for "MacPython Addons", this > project will install: > > * Hotfix for distutils to ensure that distutils builds univeral binaries > (32-bit only at first) > * (possibly) hotfix to ensure that you can install '-fat-' eggs on 10.5 > * /Applications/Python-2.5/IDLE.app > > In there future we could add other changes, such as a 'python64' command > for running python in 64-bit code. IMHO this should be done only when we > have patches python.org tree that enable 4-way universal builds on > Leopard, otherwise we'd have a real risk of loosing these changes in a > future version. > > Ronald > > On 2 Jan, 2008, at 21:33, Bill Janssen wrote: > >>> Even though I've been an open source developer since long before the >>> word existed I find that I'm getting sick and tired of the reinvent- >>> the-world attitude that is far too common in the open source community. >>> >>> If I am new to Python on the Mac and I've played with Apple Python a >>> little, but as soon as I want to install one little add-on module I >>> have to first replace the whole existing Python with something new >>> (and not directly Apple-endorsed) I might just drop out. And at the >>> very least it's mightily inconvenient. >> >> Well said, Jack! I think supporting/fixing the Apple-supplied Python >> should be a goal. I certainly used the Tiger 'Apple' Python for >> everything, living with its various foibles, and I intend to do the >> same with Leopard. I can see why cutting edge developers might want >> to have other versions installed (I've got 2.6 and 3.0 on my Leopard >> machine, for instance), but all my normal software is developed >> against /usr/bin/python. >> >> Bill > > > > > ___ > Pythonmac-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On 3 Jan, 2008, at 15:18, Andrew Jaffe wrote: Hi All, I'm not sure whether this is the correct thread/place for this, but is there any official "best practice" for Python under Leopard? This is the right thread for that (albeith one with a lame subject). I.E., should we still be using the MacPython framework build (since I assume that is more likely to track current python versions than the Apple build). Is this on the main python or macpython websites somewhere? At the moment Apple's build is a slightly patched [*] version of the current stable release of Python (that is 2.5.1), but with some small issues. AFAIK all issues are related to distutils and are easy to fix. My precious message was a call-to-arms to get a small package out that fixes the issues with Apple's build, which would result in a fully up- to-date python installation including all goodies that Apple ships (PyObjC, wxWidgets, Twisted-Core, ...) and without downloading several huge archives. Ronald [*] there is dtrace support in Apple's build and not in the official tree. Thanks, Andrew Ronald Oussoren wrote: Now that there are several people that want to support Apple's build of python: how do we go forward from here? I think we should start a small project for "MacPython Addons", this project will install: * Hotfix for distutils to ensure that distutils builds univeral binaries (32-bit only at first) * (possibly) hotfix to ensure that you can install '-fat-' eggs on 10.5 * /Applications/Python-2.5/IDLE.app In there future we could add other changes, such as a 'python64' command for running python in 64-bit code. IMHO this should be done only when we have patches python.org tree that enable 4-way universal builds on Leopard, otherwise we'd have a real risk of loosing these changes in a future version. Ronald On 2 Jan, 2008, at 21:33, Bill Janssen wrote: Even though I've been an open source developer since long before the word existed I find that I'm getting sick and tired of the reinvent- the-world attitude that is far too common in the open source community. If I am new to Python on the Mac and I've played with Apple Python a little, but as soon as I want to install one little add-on module I have to first replace the whole existing Python with something new (and not directly Apple-endorsed) I might just drop out. And at the very least it's mightily inconvenient. Well said, Jack! I think supporting/fixing the Apple-supplied Python should be a goal. I certainly used the Tiger 'Apple' Python for everything, living with its various foibles, and I intend to do the same with Leopard. I can see why cutting edge developers might want to have other versions installed (I've got 2.6 and 3.0 on my Leopard machine, for instance), but all my normal software is developed against /usr/bin/python. Bill ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
Ronald Oussoren wrote: > > On 3 Jan, 2008, at 15:18, Andrew Jaffe wrote: >> >> I'm not sure whether this is the correct thread/place for this, but is >> there any official "best practice" for Python under Leopard? >> >> I.E., should we still be using the MacPython framework build (since I >> assume that is more likely to track current python versions than the >> Apple build). Is this on the main python or macpython websites somewhere? > > At the moment Apple's build is a slightly patched [*] version of the > current stable release of Python (that is 2.5.1), but with some small > issues. AFAIK all issues are related to distutils and are easy to fix. > My precious message was a call-to-arms to get a small package out that > fixes the issues with Apple's build, which would result in a fully > up-to-date python installation including all goodies that Apple ships > (PyObjC, wxWidgets, Twisted-Core, ...) and without downloading several > huge archives. Thanks! So will this be the the right thing to do in general? Will it possible to add/replace more up-to-date packages when they come out (E.G., numpy or even Python 2.6 if it predates the next OSX)? Or will the bleeding edge always require an external framework build? For such a build, how hard is it to add in the "goodies"? (I've got easy_install working for my framework build, for example and usually use that right now.) Andrew ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On 3 jan 2008, at 14:22, Ronald Oussoren wrote: > Now that there are several people that want to support Apple's build > of python: how do we go forward from here? > > I think we should start a small project for "MacPython Addons", this > project will install: > > * Hotfix for distutils to ensure that distutils builds univeral > binaries (32-bit only at first) > * (possibly) hotfix to ensure that you can install '-fat-' eggs on > 10.5 > * /Applications/Python-2.5/IDLE.app I think that for "true" end users Idle is the only serious omission. The first one is really for developers only, and the second one doesn't really become important until such fat eggs become widely available (which they are not right now, IIRC). Hmm, idea to keep this manageable: how much work would it be to create tiny installers for each of these hotfixes, and then have a umbrella installer that encompasses all of these? That way, as new problems surface the only work would be to create a hotfix installer for that single problem and do a tiny update to the umbrella installer. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On 3 Jan, 2008, at 17:03, Jack Jansen wrote: On 3 jan 2008, at 14:22, Ronald Oussoren wrote: Now that there are several people that want to support Apple's build of python: how do we go forward from here? I think we should start a small project for "MacPython Addons", this project will install: * Hotfix for distutils to ensure that distutils builds univeral binaries (32-bit only at first) * (possibly) hotfix to ensure that you can install '-fat-' eggs on 10.5 * /Applications/Python-2.5/IDLE.app I think that for "true" end users Idle is the only serious omission. The first one is really for developers only, and the second one doesn't really become important until such fat eggs become widely available (which they are not right now, IIRC). I need to check on an unpatched system, but I'm pretty sure that setuptools will refuse to install fat eggs at the moment, and that is something that will bite causal developers (e.g. you install something like turbogears and will complain about missing eggs). Hmm, idea to keep this manageable: how much work would it be to create tiny installers for each of these hotfixes, and then have a umbrella installer that encompasses all of these? That way, as new problems surface the only work would be to create a hotfix installer for that single problem and do a tiny update to the umbrella installer. I want to do whatever keeps my live as easy as possible, either an umbrella package with small hotfix packages or one package that installs all hotfixes. I also want to keep the addon package as small as possible and don't want to end up shipping a package that patches Apple's install to 2.5.2 (whenever that is released). Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
Ronald Oussoren wrote: > I think we should start a small project for "MacPython Addons", This looks very promising. Thanks for getting it going. > this project will install: > > * Hotfix for distutils to ensure that distutils builds univeral > binaries (32-bit only at first) * (possibly) hotfix to ensure that > you can install '-fat-' eggs on 10.5 * > /Applications/Python-2.5/IDLE.app I don't have 10.5, so I'm only going on my memory of issues people have complained about on various mailing lists: * How about readline? * What about people installing upgrades to packages? IIUC, the Apple python puts stuff in a dir that is before site-packages, so if you install a newer version of a package that Apple already had, it won't be used without sys.path manipulations. I think numpy was the example at hand, but assume the same issue would apply to wxPython etc. Also, if people do upgrade packages like numpy or wxPython, or ???, might that break any Apple system stuff if there are backward compatibility issues? * Will this allow folks to build a package (or egg) on 10.5 with Apple's Python, and have it work with the Framework 2.5 python on 10.4? (and vice-versa?) * Will py2app bundle up Apple's python, or assume it exists? If it doesn't, then will it know which packages to bundle? I now I came across as a negative whiner about Apple's python early in this thread, but I think we all have the same goal here -- make it easy to use for newbies, and have it be as little work for the folks doing the real work on MacPython (not me!). If all (or most) of the issues can be resolved with the Apple supplied python, I'm all for it. Andrew Jaffe wrote: > is > there any official "best practice" for Python under Leopard? That is exactly what is being discussed here. If I have it right, then Ronald is proposing that a modest "hotfix" package will solve the few issues with the Python Apple supplies with 10.5, so we, as a community, can declare using it as a "best practice". We can then update the appropriate Wiki pages (and that I could actually help with!) Jack Jansen wrote: > I think that for "true" end users Idle is the only serious omission. This is where I disagree -- what is a "true" end user? It's a complete continuum, from total newbie to hard-core hack-at-the-cpython-source developer. And, indeed, we hope that the newbies will move up the continuum as they get more experience. > The first one is really for developers only, Who is a "developer?". I agree that folks like Ronald (for PyobjC) and Robin Dunn (for wxPython), can patch their systems to build binary packages the way they want. However, a LOT of binary packages for OS-X are build by folks different than the people developing the packages. These vary from newbies that download a tarball with instructions to type: "setup.py install", to folks like me that are less newbie, but really want a one-way-to-do-it package that I can give to my colleagues etc, and have it run on multiple systems, to folks that are trying to get an app bundled up with py2app that lots of other folks can run. Ever since OS-X began, the net has been littered with various binary packages for python that are all compatible with different pythons: Apple's, fink, darwinports, Intel Only, PPC only,etc, etc, etc. It really will do the community a lot of good to consolidate that as much as possible, and having the "best practices" python build the "right" kind of package by default is critical to this. Someone wanting to build and distribute a packages needs to be able to find instructions not more complicated than: 1) Download and install this: [hotfix package] 2) setup.py build 3) bdist_mpgk (or whatever the setuptools command is to build a binary egg) > and the second one doesn't > really become important until such fat eggs become widely available > (which they are not right now, IIRC). I don't know how you define widely, but they are becoming available -- matplotlib, scipy, numpy, etc. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On Jan 3, 2008, at 10:27 AM, Ronald Oussoren wrote: >> I think that for "true" end users Idle is the only serious >> omission. The first one is really for developers only, and the >> second one doesn't really become important until such fat eggs >> become widely available (which they are not right now, IIRC). > > I need to check on an unpatched system, but I'm pretty sure that > setuptools will refuse to install fat eggs at the moment, and that > is something that will bite causal developers (e.g. you install > something like turbogears and will complain about missing eggs). >> It seems to be working for me. Some source I compiled builds a python wrapper (swig-based), which also depends on numpy. I used ARCHFLAGS to build quad-arch: export ARCHFLAGS="-arch ppc -arch i386 -arch ppc64 -arch x86_64" With "make install" it uses setup.py's setup(), which works with no errors. The zipped egg the build process generates also installs with easy_install with no errors. The egg is named with only the build system's arch, i386. I don't see anything in the egg-info or easy- install.pth that identifies the architectures, other than the egg name. I haven't done any patching to the system's python. - William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
> * Hotfix for distutils to ensure that distutils builds univeral > binaries (32-bit only at first) Is there a bug # for this? Possibly with a patch that we could start with :-? Bill ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On Jan 3, 2008, at 5:27 PM, Ronald Oussoren wrote: > I want to do whatever keeps my live as easy as possible, either an > umbrella package with small hotfix packages or one package that > installs all hotfixes. I also want to keep the addon package as > small as possible and don't want to end up shipping a package that > patches Apple's install to 2.5.2 (whenever that is released). Sounds great! BTW, we had a very inspiring discussion on the zope3-dev list last summer regarding system python for *development*. Most people there prefer a separate python tree for each (zope) project. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08490.html A current Zope Components (formerly known as Zope3) based Application crashes with Leopard's system python because of the twisted package, which brings in a dated zope.interface egg (BTW, the unpacked egg as well). I'm extensively using zc.buildout for my projects. And not only for zope development. I love to have an unpolluted reconstructible python environment for each project and leaving the system python untouched. I am now thinking about setting up a buildout for Leopard's python. Cheers, Tobias ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On 3 Jan, 2008, at 18:42, Bill Janssen wrote: * Hotfix for distutils to ensure that distutils builds univeral binaries (32-bit only at first) Is there a bug # for this? Possibly with a patch that we could start with :-? There is a fix in python's repository. I'll have to look up the details, but it was a bad version comparision (testing for <= 10.4. instead of >= 10.4 IIRC). I'm planning to start work on this next weekend, starting with the distutils issues. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On 3 Jan, 2008, at 19:28, Tobias Rodäbel wrote: On Jan 3, 2008, at 5:27 PM, Ronald Oussoren wrote: I want to do whatever keeps my live as easy as possible, either an umbrella package with small hotfix packages or one package that installs all hotfixes. I also want to keep the addon package as small as possible and don't want to end up shipping a package that patches Apple's install to 2.5.2 (whenever that is released). Sounds great! BTW, we had a very inspiring discussion on the zope3- dev list last summer regarding system python for *development*. Most people there prefer a separate python tree for each (zope) project. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08490.html I'm starting to get hooked on virtualenv (to be found on pypi.python.org). This allows you to have seperate python trees based on a single installation. You can, but don't have to, share the global site-packages directory and every install has its own site-packages as well. This is very convenient when working on several projects, every one can have its own tree without having to install python several times. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
Christopher Barker wrote: > * What about people installing upgrades to packages? IIUC, the Apple > python puts stuff in a dir that is before site-packages, so if you > install a newer version of a package that Apple already had, it won't be > used without sys.path manipulations. I think numpy was the example at > hand, but assume the same issue would apply to wxPython etc. If the upgrade package is an egg then the new egg will be found first. If the upgraded package just drops itself into the standard or user site-packages or something then the Apple installed packages will be found first unless there is some manipulation of the path. $ /usr/bin/python -c "import sys,pprint; pprint.pprint(sys.path)" ['', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload', '/Library/Python/2.5/site-packages', '/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/PyObjC', '/Users/robind/Library/Python/2.5/site-packages'] -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Leopard easy_install chokes on appscript egg
On 31 Dec 2007, at 14:09, Ronald Oussoren wrote: [cc.d to Bob for his info] >>> That's a buglet in Python, fixed in what will be 2.5.2. Apple's >>> python doesn't do universal binaries and setuptools doesn't know >>> that an 'fat' egg will do on a 'ppc' or 'i386' platform. After further poking, it does appear as if 10.5's Python is building extensions as UBs; it's just misnaming the eggs as ppc/i386. >> OK, ta. Any advice on creating .eggs that will work for 10.5's >> brain-damaged Python install, both for PPC and i386? (While I have >> 10.4 on both PPC and i386, I have 10.5 on i386 only.) > > Patching the Makefile for python is probably the easiest way, that > is add '-arch i386 -arch ppc' to BASECFLAGS and LDFLAGS and set > UNIVERSALSDK to '/' (otherwise the architecture will be wrong). You > might also have to patch distutils to work around a bug in there. Mmmmkay. I've decided to cheat, building a universal .egg for user-installed Python 2.5 and separate 'ppc' and 'i386' eggs for Leopard Python (I don't have 10.5 on PPC, so I made myself a PPC-only python interpreter and it seems to create 'ppc' eggs okay under Rosetta.) 2. I get the above traceback when easy_install tries to use the source- based appscript. [...] >>> >>> My guess is that this a buglet in setuptools sandboxing code. Can >>> you build an egg using Apple's python and install that (that is >>> run 'setup.py bdist_egg' and then install that egg. >> >> >> The following seems to work ok: >> >> cd appscript-0.18.0 >> /usr/bin/python setup.py bdist_egg >> cd dist >> /usr/bin/easy_install appscript* > > You might want to ask on [EMAIL PROTECTED] about this. The error itself is occurring when importing the skipjunk function from py2app, so it might be best if Bob takes a look first to see if the problem is at py2app's end. In the meantime, I disabled the skipjunk-related bits from setup.py, and 'easy_install appscript' now works as intended. The bdist_mpkg option is broken, however (either due to removing that code or to other bugs), so I've just disabled the lot for now and slung up an 0.18.1 update on PyPI (I've still to update the sourceforge site though). Not entirely happy that I don't have a working binary installer available for Tiger's Python, but I don't have the time to be dealing with all this stuff right now (plus I just bought a new laptop and don't want to bounce it off the walls just yet). If anyone else has a bit of free time and wants to create a more satisfactory solution then be my guest; just drop us a note and I'll be happy to put it up. ... Anyway, assuming there's no more reports of problems in the next few days I'll call py-appscript-0.18.x a done deal [1]. If folks here would like to try installing appscript via 'easy_install appscript' in the next day or two and let me know if there's any more problems then I'd really appreciate it. Thanks again, has [1] Next step is 0.19.0, which is a significant stripping down and reorganisation of the current distribution and [hopefully] the long- awaited beta 1 release. -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Possibly OT: Get path to icon file for PIL?
I'm looking for a Python API that will return the path to an icon file which I can then read via PIL and display in my application. The available API's that I can find--NSWorkspace and IconServices--provide various hooks to obtaining and displaying an icon, but neither appears to support finding the source file for an icon. For instance, I can use something like this in Cocoa to get an icon: NSWorkspace * ws= [NSWorkspace sharedWorkspace]; NSString* path = [ws fullPathForApplication:@"Safari"]; NSImage * icon = [ws iconForFile: path]; but while this obtains the icon data, it doesn't tell me where the original file is. My purpose here is to take advantage of PIL's ability to read icns files without having to rewrite my application entirely in PyObjC. Would another approach work? I've looked into using plistlib to parse plist files, but that seems too haphazard. AppleScript also lists an API for finding icons, but it's not implemented. Any advice is appreciated. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Possibly OT: Get path to icon file for PIL?
On 3 Jan, 2008, at 23:08, Kevin Walzer wrote: I'm looking for a Python API that will return the path to an icon file which I can then read via PIL and display in my application. The available API's that I can find--NSWorkspace and IconServices--provide various hooks to obtaining and displaying an icon, but neither appears to support finding the source file for an icon. For instance, I can use something like this in Cocoa to get an icon: NSWorkspace * ws= [NSWorkspace sharedWorkspace]; NSString* path = [ws fullPathForApplication:@"Safari"]; NSImage * icon = [ws iconForFile: path]; You can do this through the bundle API (open the bundle for an application, look up the name of the icon from the Info.plist and then locate that icon. Something like: path = ... bundle = NSBundle.bundleWithPath_(path) info = bundle.infoDictionary() iconName = info['CFBundleIconFile'] iconPath = bundle.pathForResource_ofType_(iconName, 'icns') Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
