I would like to continue improving and adding to TouchCode, but my time is finite and I’m unable to work on it as much as I would like. So when I do work on TouchCode, I appreciate that other people rely on the code and as such I make it a priority to fix bugs before adding new features or components. Other contributors to TouchCode have helped a lot. A lot of bugs and memory leaks have been found and fixed. This is all great. But it is obvious that TouchCode needs more work, it especially needs more unit tests and documentation. To help make time available to improve this I’ve decided to ask TouchCode users for donations via PayPal.

• You do NOT need to donate to use TouchCode (the code is still Open Source under very permissive licenses).
• TouchCode will always remain Open Source. Donations will not change that.
• Donations will be set aside and will allow me to spend more time working on TouchCode – especially the less sexy fun of TouchCode. I will not be using the funds to buy a new MacBook Pro (however tempting that may be).
• Donations will be made with no strings attached. I will not be adding feature X to component Y just because you’ve donated to the project. However if you have an urgent need for something in TouchCode (output support in NSXMLDocument perhaps?) contact me and we can talk.
• No donation too small, no donation too big. Every donation appreciated.

And here’s the PayPal donate button:

TouchMap.mov

While it was really gratifying to be recognised by the judges of the competition, it was even more gratifying to see portions of TouchCode in use by the some of other winning contestants. The Taxi application in particular stood out as a great use-case for TouchJSON and I really expect Taxi to sell like hot cakes when it gets uploaded to the AppStore.

I had a great time talking to other iPhoneDevCamp attendees, some of which wanted to thank me for parts of TouchCode. Other attendees were interested in the project and I relished the chance to tell them all about. Hopefully I’ll be able to add more projects to my “who uses TouchCode” blog post.

So far I’ve added three projects to the repository:

• TouchXML: A Foundation NSXML style API for parsing XML files (based on libxml2)

• TouchSQL: Yet another library for talking to sqlite databases. This is actually old code that I’m bringing up to date for 10.5, the iPhone and objc-2.0

• TouchJSON: My [CocoaJSON] project brought up to date.

I’m trying to add Unit Tests and documentation to all three projects so they’ll be suitable for public consumption.

Tim Burks has also graciously added nu makefiles and unit tests for each project too. Thanks Tim.

Oh and…

Yes I am potentially interested in iPhone related consulting work. jwight@mac.com

I’ve written an Automator action that allows you to write python scripts directly inside your Automator workflow.

“Run Python Script” Automator action (catchy title) is written using Python and PyObjC (now built-in to Mac OS X 10.5). Apple already provides “Run AppleScript” and “Run Shell Script” actions with Automator which give Automator a high degree of flexibility. However Python is my preferred scripting language and by writing a custom action purely for Python I was able to take advantage of some PyObjC features that in my opinion make my action superior to the provided Apple scripting action. I’m releasing all the source code to the action under the BSD Open Source license.

One of the main advantages of the action is that Python (with the help of PyObjC) understands the AppleEvent descriptors that Automator uses to pass data between workflow actions. This allows the user to create a custom action that accepts and provides data of any type. In contrast Apple’s “Run Shell Script” action can only accept and provide text (usually limited to file paths). Some work does need to be done to make working with any data (which is represented by NSAppleEventDescriptor objects) more convenient.

The default Python script for a new action in a workflow follows:

import sys

def main(input, *args, **kwargs):
    '''Your script goes here.'''
    print 'Hello world'
    return sys.stdout

This is pretty simple. The action will optionally convert the input into Python types (currently limited to converting typeAlias AppleEvent descriptors into path strings) to allow simple processing. Output is (optionally) converted from Python types to native Automator types. See the Examples directory for more.

The following screenshot shows the action used in a real workflow. This workflow asks the user for a keyword and then the Python action downloads photos from the morguefile public stock photo archive that are related to the keyword. Once download it performs some processing on the files (scales them to 640 by 480) and produces a PDF “Contact Book” from the images.

The source code uses a 10.5 specific technique to create Python based bundles. It also has a simple Python syntax colouring NSTextView (using Python itself to colourise the source).

I’m calling the Action a 0.1 release and have some plans/ideas for further releases. See the TODO list.

Update: I’ve added a sample script showing how to upload files to Amazon S3 from within a workflow.

The code in subversion is a lot newer than the binary I’m linking to. If possible do a checkout and build the plugin yourself.

Update: This Automator action has issues on Snow Leopard and some Leopard versions. Use at your own risk.

Update: Automator’s “Run Terminal Script” looks like it supports and understands Python native. That means, although my .action was better (syntax highlighting, better control of input and output, better logging, etc), I probably won’t bother to update it to Snow Leopard.