Using Firefox as Flash playing Safari fallback

If you want to go Flashless on Mac and Safari, it's possible to use Firefox as a fallback, too, not just Chrome. While Firefox does load Plugins from /Library/Internet Plug-Ins and ~/Library/Internet Plug-Ins, it looks in other places too. I just tested and it seems to work fine from ~/Library/Application Support/Firefox/Profiles/<profile name>/plugins and I suspect /Applications/ would work too.

So you can copy Flash Player.plugin, NP-PPC-Dir-Shockwave and flashplayer.xpt to one of the Firefox specific folders and launch Firefox from Safari's Developer menu. Chrome starts up faster, though.

Article page

xibgraph: Interface Builder overviews

When putting together user interfaces with Interface Builder, you connect things together with bindings, actions and outlets and it's good. Understanding the result later on is a completely different matter. It can be time consuming and difficult to browse the objects inside one by one, trying to comprehend the whole. Even more so if you're trying to read someone else's work.

Out of that frustration came xibgraph. It takes a XIB file and outputs the connections contained inside:

Example xibgraph output

At the moment it supports bindings and actions. Outlets are next.

xibgraph supports a couple of different output formats. JSON is supported out of the box and if you install pydot, you get DOT, the format understood by Graphviz and OmniGraffle too.

It hasn't been tested on a particularly wide variety of XIBs, so it's very plausible it will produce wonky results or just outright refuse to work with your files. If so, patches and bug reports are welcome.

xibgraph is MIT licensed and written in Python. It requires PyObjC (it seemed like the easiest way to get XPath support on OS X) and probably Python 2.6. Everything but the DOT support should work without additional requirements on OS X 10.6.

Article page


I usually use Murky, dvc or some other shell for Mercurial. Not always though, for various reasons, and when running hg status I'm always frustrated when copy and pasting file names. bzr provides neat, non-cluttered lines that can be copied whole to get a file name without a hassle, but hg takes the traditional one-character prefix approach to status display and as a result makes you manually select a part of a line instead of just grabbing a whole line.

So I wrote a small extension to help. Meet hg-status-sections.

Article page

A better @synthesize

The biggest problem with Objective-C's @synthesize directive for properties is how difficult it's to augment the synthesized code. You often need to add logic to a property setter, but while you're adding it, you're losing the probably correct implementation Apple's code creates for property flags like atomic and retain.

At the moment, when you synthesize a readwrite property called foo you get a setter method called setFoo. If you need to add logic around it, you can either store the value in a private property and add a public property with a different name or use a subclass. Both are a bit of a hassle. Usually I just end up writing my own method, including the logic for implementing the modifiers correctly.

In an ideal world the language would support something like around/before/after methods in CLOS, but those features are rare. There's a simple way @synthesize could make things easier without requiring massive changes to the runtime. It could give you for both the getter and setter two methods. There would be the public methods they create in the current implementation, but there'd also be methods with names like __synthesized_property and __synthesized_setProperty. The public methods would rely on the semi-private methods to actually implement all their logic. Then if you needed to add logic around the accessors, you could override the public methods and call the semi-private ones to get access to the synthesized accessor logic without jumping through hoops or risking getting the implementation wrong.

Article page

Block indentation in Emacs

There are several small things Emacs could be doing to make it nicer to write code. One I was missing was making it possible to go with one press of the return key between braces in a C derived language from this:

if (test) { }

to this:

if (test) {
   <-- insertion point here

That is, pressing return before the closing parentheses, brace or bracket should move the closing character two lines down, indent it properly, and move the insertion point to the new empty line in the middle and indent it property. The way TextMate does it.

Here are a few of elisp functions to accomplish this:

(defun char-isws (c)
  "Is character c a whitespace character?"
  (or (char-equal c ?\ )
      (char-equal c ?\t)
      (char-equal c ?\n)))

(defun line-next-non-ws ()
  "Return the next non-whitespace character on the current line or nil."
  (let ((cc (char-after)))
    (if (and cc (char-isws cc))
          (if (re-search-forward "[^[:space:]]" (save-excursion     (end-of-line) (point)) t)

(defun newline-and-indent-extra-for-closing-paren ()
  "Insert a newline and indent. If the next non-whitespace character is a closing paren, insert two newlines and indent the two  new lines correctly, placing the point on the first of the two new lines."
  (let ((nc (line-next-non-ws)))
    (if (or (null nc)
            (not (= (char-syntax nc) ?\))))

Now you can bind return to newline-and-indent-extra-for-closing-paren in a suitable language keymap. I've been using this with scala-mode and it works well there.

Article page

Exporting geolocation data from iPhoto with AppleScript

I recently transferred all my photos to iPhoto. I share them on Flickr, but I've been unhappy with iPhoto's built-in Flickr support — it has an arbitrary 500 photo limit on web album size, it's crashy, it does weird synchronizations that take ages when combined with lots of large photos and a slow internet connection, it has multiple times failed to send all the full-resolution images — so I've been exploring alternatives. There's at least FlickrExport and Flickr's own Uploadr.

Although the tools work, there's a downside compared to iPhoto's built-in Flickr support. iPhoto has wonderful geotagging support, as does Flickr, but iPhoto doesn't write the data to EXIF tags and that poses a problem for the tools. Uploadr reads just the files and so never sees the data, and apparently iPhoto doesn't provide the data to FlickrExport, either. The result is that Flickr won't know the locations of the photos.

There's a way to work around this problem. The solution is AppleScript. iPhoto exports photo objects that can tell you their location as set inside iPhoto. The downside to this approach is that it's AppleScript, but apparently the alternatives like Python or JSTalk aren't quite up to tasks like these without application support.

This script will write the locations of the selected photos relies on ExifTool. It will litter your photo directory with files ending with _original that should contain the unmodified images. You should make sure the modified files are ok before deleting the originals. The usual caveats apply: I'm no AppleScript expert and this has not been tested particularly rigorously. I'd be careful especially if you don't live in the NE hemisphere. And you might want to reduce the number of dialogs. Do what you want with it.

-- This applescript will geotag the selected photos with the
-- location information set in iPhoto.
--   You must have exiftool installed; by default it's loaded from
-- /opt/local/bin, where MacPorts installs it from the package
-- p5-image-exiftool.
-- Author: Juri Pakaste (
-- Based on the Set Geo Data.scpt script by
-- Andrew Turner (
property exifToolOriginal : "_original"
property exifToolPath : "/opt/local/bin/exiftool"

on extract_decimal(realnum)
   set res to realnum - (round realnum rounding down)
end extract_decimal

on roundFloat(n, precision)
    set x to 10 ^ precision
    (((n * x) + 0.5) div 1) / x
end roundFloat

on d2s(degs)
    log "enter d2s"
    if the degs < 0 then
        set the degs to degs * -1
    end if

    set the degrees to round degs rounding down
    set the minssecs to extract_decimal(degs)

    log "minssecs: " & minssecs

    set the minssecs to minssecs * 60
    set the mins to round minssecs rounding down

    set the minssecs to extract_decimal(minssecs)
    log "minssecs 2: " & minssecs
    set the secs to minssecs * 60

    "" & degrees & "," & mins & "," & roundFloat(secs, 2)
end d2s

on exportCoords(image_file, lat, lng, alt)
    set the northSouth to "N"
    set the eastWest to "E"

    if the lat is less than 0 then
        set the northSouth to "S"
        set the lat to the lat * -1
    end if

    if the lng is less than 0 then
        set the eastWest to "W"
        set the lng to the lng * -1
    end if

    log "calling d2s on " & lat
    set the latstr to my d2s(lat)
    set the lngstr to my d2s(lng)

    set exifCommand to exifToolPath & " -GPSMapDatum=WGS-84     -gps:GPSLatitude='" & latstr & "' -gps:GPSLatitudeRef='" & northSouth     ¬
        & "' -gps:GPSLongitude='" & lngstr & "'     -gps:GPSLongitudeRef='" & eastWest ¬
        & "' -xmp:GPSLatitude='" & latstr & northSouth & "'     -xmp:GPSLongitude='" & lngstr & eastWest & "'     -xmp:GPSMapDatum='WGS-84'" & " -xmp:GPSVersionID=''" & " " & quoted form of image_file
    display dialog of ("running: " & exifCommand)
    set output to do shell script exifCommand
    display dialog of output
    --do shell script "rm '" & image_file & "'" &     exifToolOriginal    
end exportCoords

tell application "iPhoto"
        copy (my selected_images()) to these_images
        if these_images is false or (the count of     these_images) is 0 then ¬
            error "Please select one or more images."

        repeat with i from 1 to the count of these_images
            set this_photo to item i of these_images
            tell this_photo
                set the image_file to the image path
                set lat to the latitude
                set lng to the longitude
                set alt to the altitude
            end tell

            if lat < 90.1 and lng < 180.1 then
                my exportCoords(image_file, lat, lng,     alt)
                display alert ("No location set for "     & name of this_photo)
            end if

            log "read image, lat: " & lat & ", lng: " &     lng

        end repeat
        display dialog "Geo Exif write complete."
    on error error_message number error_number
        if the error_number is not -128 then
            display dialog of ("failed on: " & image_file)
            display dialog error_message buttons     {"Cancel"} default button 1
        end if
    end try
end tell

on selected_images()
    tell application "iPhoto"
            -- get selection
            set these_items to the selection
            -- check for single album selected
            if the class of item 1 of these_items is album     then error
            -- return the list of selected photos
            return these_items
        on error
            return false
        end try
    end tell
end selected_images

Update (2010-02-28): Thank you to @simonmark on Twitter, who pointed out the script had some issues. My version broke if file names had single quotes in them and Simon's version broke with double quotes (admittedly probably rarer in file names.) I was going to leave it as it was, but found the quoted form method of text objects in AppleScript Language Guide which, assuming it works correctly, should make the script always work properly (at least in terms of file name handling.) I also copied Simon's better error display code and replaced the extract_decimal implementation with something that isn't quite as silly as my previous version was.

Update (2010-06-02): I set up a Bitbucket repository for this and other scripts I've written for iPhoto.

Article page