I decided I’d share what I’ve learned recently to make getting started a little easier. I’ll give a short description here and post the resulting code to bitbucket at py-launchd.

Note: This was written and tested on OS X 10.5.8 with the default /usr/bin/python, version 2.5.1. Since I wanted to use multiprocessing, I used the backport to 2.5 available at google code: python-multiprocessing . For convenience, it’s included in the repository, and so is its license.

Goal

What we’re trying to do is have some python code that gets called when launchd notices someone connecting to a UNIX domain socket. UNIX domain sockets are local-only, so this is ideal for agents that only serve local apps. We’re also using launchd “agents” not “daemons”, so we’re assuming that it’s OK to have one agent process for each user. If you’re managing access to something that needs to be unique system-wide, then this won’t work (but you can still use Launchd).

launchd overview

The launchd process will read a launchd plist you give it (at login, via launchctl or the 10.6 framework), and listen on the socket you tell it to. Once it sees a connection, it’ll start the agent program you specified in the plist, and that program can make some calls using the launchd C API to get a file descriptor for the socket that was connected. This is important – you don’t need to call bind() or listen() on the socket, because launchd already did. It’s just handing the open socket’s file descriptor straight to you and your code can just call accept() on it.

Using launchd with Python

You need to create a C/ObjC tool that can do the launchd check-in to get the open file descriptor, then pass that off to your Python code. This is pretty straightforward using the Python framework included in OS X and the Python C APIs.

What I’ve done is create an agent loader that I called PyLaunchd that loads and runs server code in Agent.py. It expects Agent.py to be in the same directory.

PyLaunchd is built separately and copied into the test app’s Resources folder with an XCode script phase.

I have the app delegate copy PyLaunchd and Agent.py to ~/Library/Application Support/PyLaunchd/ on loading. It also customizes the launchd plist to set the path correctly for the current user, then writes that to ~/Library/LaunchAgents/, and loads it. (Actually it first unloads it, then reloads it. I’m not convinced this is the right way to do it). It uses system() to call launchctl, but I believe in OS X 10.6 there’s an API you can call to do it directly.

Finally, the sample app is really simple – it just opens the socket using the multiprocessing Client class, and sends whatever you type. The example Agent I’ve included will ROT13 it and send it back.

Please let me know if you have any comments, questions, or improvements.

I love it when I can guess how to do something new in a program. Skim just did this for me – I needed to figure out how big the rectangle of text in a paper I’m working on is, in inches. I looked for rulers, and then decided I’d just see if I get any size feedback when I make a rectangular selection. Turns out there’s a nice feedback status line in the bottom right – clicking toggles between measurement in pts and in inches.

I like how this solves my problem without adding a lot of new UI for measurement – no rulers, no extra tool to measure length.

Anyone could nominate an app, and the developer community would vote on who wins, in just a few categories.

I’m thinking the categories could be a little more user-centric than Apple’s. For instance, I don’t really care about best adoption of OS X technologies, but something like “best refinement of a common task” or “best default behavior” or “best scriptability” would be interesting, and something that’d be easier to use as a marketing badge…

This is just off the top of my head, so there are probably others. “Least data lock-in”? “Easiest to learn?”, “Best plugin community”?

I made a view that displays a zoomed out view of a string from a text view, with indentation, along with a rectangle showing where the text view is in the file.

You can click around in the view to move the It also highlights the selection, and draws lines in blue if they contain the string in the NSFindPBoard, so you can see all the lines in the file that match when you use the Find panel.

This is available under a Creative Commons license, and I’d ask that if you make any improvements, you send them back to me or join the ‘leverage’ sourceforge project, where the code is hosted. I wanted to eventually make this into a Cocoa text plugin like my I-Search plugin.

Here is the SVN repository for the textshape code.

There was also a Source code Tarball with a demo app, shown in the screenshot below:

Mac OS X LocationChanger – TECH.inhelsinki.nl.

It’s great to see new life for one of the few alternative desktop mail clients for OS X, and while there’s no info on their plans for it yet, there’s some great discussion of possible features on the google group mailsmith-talk.

I’ll be curious to see if any of the design choices will be changing – for example, no IMAP support and no inline HTML display… I have to use IMAP, and despite common abuse, I do think HTML email is useful.

edit: Looks like no Mailsmith IMAP: “Not any time soon…” – @siegel on twitter

Teams at apple are TINY. Mail is like 3 guys. …

Two things: The thread was about how high quality software is easier without politics you get in large teams, which I agree with, and I bet that a lot of the software we love was made by smaller teams than you’d think.

And, just 3 engineers on Mail explains a lot.

I use EagleFiler to keep track of reference documents that I get in emails. Presentations, reports, etc – the kind of thing that would usually just get stored in the mail archive. Because I want a complete mail archive and a fast way to get to the important stuff, I keep the important stuff in EagleFiler so I can add tags and searches don’t get a lot of false hits.

Of these, the only one that’s polished enough to lure me away from emacs and seems to support my favorite mode of working is Cornerstone, and it still gets it a little wrong.

I like to write log comments while looking at (and scrolling through) the diffs for the files I’m committing. This means I want a text field for writing log comments on the same screen as the diffs, that isn’t modal, and doesn’t stop me from moving around between multiple diffs.

As far as I could tell, I couldn’t get the comment field and the diff display shown together in Versions, and while I could in ZigVersion, that app had a subpar diff display and lacked polish overall, missing key shortcuts where I’d expect them, for instance. Cornerstone almost lets me do what I want, but it displays the comment field in a modal sheet, so I have to cancel to change which diff I’m looking at.

This is easy in emacs, but I like a nicer diff GUI. Am I just missing something? This feels like a natural workflow, so it seems strange that no clients support it well.