Bear's Log

For Chandler's OS X install we take the tried-and-true method of building an application bundle directory structure and running it thru a make-disk-image script that from the looks of it has been passed around a lot :)

Here is the layout that Chandler uses:

• Chandler.app/
• Contents/
• Info.plist
• MacOS/

• ChandlerApp

  • Resources

• Library

• all the other source and resource files for Chandler

Now, when we are just letting Chandler get started by double-clicking on the Chandler.app icon, everything worked well. The contents of Info.plist points to the ChandlerApp shell script which in turn sets up the various python environment variables and then runs the python binary that is buried in the very long path that is buried inside of the Library/ directory. Chandler starts, events happen and all is good :)

But, when you try to start Chandler using the terminal inside of the Resources/ directory you get the very helpful error message:

    This program needs access to the screen. Please run with 'pythonw',

    not 'python', and only when you are logged in on the main display of

    your Mac.

Huh! was my first reaction, followed quickly by "ok, lets find pythonw."

After searching for a bit (longer than I care to admit), asking on some IRC channels and so on, I finally found that all pythonw is for Python 2.4 on OS X is nothing but a shell script that points to the Python binary (not the capitilization) that is deep inside of the Python Framework! So, after sitting and staring at the one-line-script-that-pretends-to-be-something-mystical for a couple minutes, I realize that either something is being set in the environment or there are files and/or directories present in the Framework that are normally not present when you create an application bundle.

After doing some simple comparisons of well placed "set > set.log" I determined that it wasn't any obvious environment variable so I started futzing around with the sibling directories of the Python binary. My first test was just to copy the whole lot of them into Chandler's Resources/Library/ directory and try to run it.

After tweaking with the environment variables in our RunChandler script, voila! it worked!

To make a long rambling post a bit shorter, it turns out that once you provide the Framework, ummm, "framework" inside the application bundle, you are able to run the .app as both a double-click and also a command-line app. Right now there are some duplicate files that need to be symlinked to reduce the size of the .dmg - but it works.