<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:series="http://unfoldingneurons.com/"
	>

<channel>
	<title>Tom Gidden &#187; mac</title>
	<atom:link href="http://gidden.net/tom/tag/mac/feed/" rel="self" type="application/rss+xml" />
	<link>http://gidden.net/tom</link>
	<description></description>
	<lastBuildDate>Sun, 01 May 2011 10:35:37 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Space Honker v.0.1 for Mac</title>
		<link>http://gidden.net/tom/2011/01/17/space-honker/</link>
		<comments>http://gidden.net/tom/2011/01/17/space-honker/#comments</comments>
		<pubDate>Mon, 17 Jan 2011 21:46:24 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Programming]]></category>
		<category><![CDATA[cocoa]]></category>
		<category><![CDATA[honk]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[punctuation]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=157</guid>
		<description><![CDATA[On Thursday, Farhad Manjoo of Slate vented his spleen about those of us who use two spaces after their full stops, a.k.a. "periods". This seems to have triggered a minor kerfuffle, though not for the first time. While I disagree with a few of his points, the premise is sound. Unfortunately I, like many others, have double-spacing ingrained.  This app might help.

Manjoo's argument seems to ramble a bit. It's allegedly a holdover from monospaced typewriters, but the width of two spaces in a monospaced font is much more significant than under in a proportionally-spaced font.  Eh?
He also claims that "Monospaced fonts went out in the 1970s" and "we've all switched to modern fonts" [my emphasis]. Well, sorry, but we haven't all switched to modern fonts, as I think many programmers, screenplay writers and lawyers will attest. I use monospaced fonts every day, and I read and write all email in the wonderful Monaco typeface that comes with every single Mac.
His argument has been picked up by others, both pro- and con-. I will let them argue it.
Enough of a rant from me, though. As I said, I do agree with the overall premise, but how to switch? Habits are hard to break. Rigging up some sort of taser seems excessive, but an obnoxious noise should do the trick.
The result is Space Honker, version 0.1 (build 0002). This is a small app for Mac OS X which sits in your menu bar and watches what you type. As soon as you type a dot (or an exclamation mark, or a question mark, or a colon, or a semicolon, or a comma) followed by two spaces, it should make an irritating noise. Just to rub it in a bit more, it'll update a counter to tell you how many grievous sins against typography you've made.
It will only trigger if you hit the keys in order, so if you type the full stop and then mess about somewhere else in the sentence and then return and type the spaces, it will not trigger.
It's the product of about two hours' work, so by no means the best piece of code I've ever written (to the point that I'm not releasing the source publicly for fear of embarrassment) but it might work.
Feel free to download it and try it, but at your own risk: I haven't put anything that I know to be nasty or malicious in it, but you never know. Oh, and if it fails to pick up a sentence and you get marked down for bad punctuation, that's also Not My Problem.
Please let me know how you get on with it. Next up: something to cure me of my unhealthy dependence on the ellipsis…
The Methodology
If you're a programmer, you might want to check the method I'm using:  it uses NSEvent's addGlobalMonitorForEventsMatchingMask:handler: to listen to all keyDown events in the system. On keyDown, it checks to see if it has a known unichar for the incoming keyCode, stored in two unichar[65536] arrays: one for shifted, one for unshifted. If not, it uses [event characters] to get the unichar for the key, and if it's reasonable, it'll store the result. Otherwise, it'll mark that array entry as -1, ie. no match. By caching values, it reduces the amount of NSString lookups that would otherwise occur on every single keypress.
If it finds a chain of one of the specific punctuation marks, followed by two spaces, it'll honk.
Anyway, if you're a competent Cocoa programmer and you want to take the code off my hands and clear it up, buzz me. Otherwise, best of luck.
The sound effect is by Stickinthemud, and came via Freesound, and is licensed under a Creative Commons Sampling Plus 1.0 License. Thanks!
Incidentally, Space Honker triggered 16 times in the process of writing this post. Heh.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2011/01/17/space-honker/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Extracting pages from PDFs on OS X</title>
		<link>http://gidden.net/tom/2009/01/27/extract-pdf-pages/</link>
		<comments>http://gidden.net/tom/2009/01/27/extract-pdf-pages/#comments</comments>
		<pubDate>Tue, 27 Jan 2009 16:54:18 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Programming]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[pdf]]></category>
		<category><![CDATA[xcode]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=66</guid>
		<description><![CDATA[I need to slice and dice a lot of images from a number of multi-page PDF files, but I don't happen to have the right bit of ImageMagick installed on my MacBook Pro.  Instead, I took the slightly longer route of writing a utility to do it.

Mac OS X comes with a neat little utility called "sips" which can be used to transcode images and PDFs.  However, I haven't found any way of telling it to choose a particular page of a PDF file.  I've googled a bit on the subject, and couldn't find anything.
Of course, I could manually extract the pages using "Preview" but there's no fun in that.
ImageMagick would also usually do the trick, but I haven't installed GhostScript as part of ImageMagick, so PDF file support is fairly broken.
Anyway, extracting pages should be a fairly simple thing to do, considering OS X's drawing layer is very closely related to PDF.
I've put the code in my Subversion repository here, so you can extract the XCode project by running:
svn co http://gidden.net/svn/ExtractPagesFromPDF/
at the command-line.
The code is very basic, and doesn't handle encrypted PDFs or anything special, so treat it as "sample code".  Also, I'm no XCode/Objective-C/CoreGraphics expert by any means, so this may not be the best way of doing it!  No warranties, blah blah blah.  Use at will and at your own risk.
How to use:

Build the project in XCode
Get the executable file, "ExtractPagesFromPDF" and put it somewhere in your $PATH
ExtractPagesFromPDF myBigDocument.pdf
The subpages should be created in the current directory, with the format %04d.pdf (ie. 0001.pdf, 0002.pdf, ...).  If you have files with those names already, move them out of the way!

Now that's written, I can now use "sips", "ImageMagick", etc. to continue the processing I need to do for the project.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2009/01/27/extract-pdf-pages/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>EyeTV 3</title>
		<link>http://gidden.net/tom/2008/01/16/eyetv-3/</link>
		<comments>http://gidden.net/tom/2008/01/16/eyetv-3/#comments</comments>
		<pubDate>Tue, 15 Jan 2008 23:51:00 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Reviews]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[Elgato]]></category>
		<category><![CDATA[Elgato-EyeTV]]></category>
		<category><![CDATA[EyeTV]]></category>
		<category><![CDATA[EyeTV-3]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[OS-X]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2008/01/16/eyetv-3/</guid>
		<description><![CDATA[I've been a dedicated user of EyeTV for almost two years, to the point that I no longer watch TV on the big screen in the living room.  Instead, I watch almost exclusively on my iBook.  Back in May 2006, I wrote a post about EyeTV 2.2 and its shortcomings.  Today, Elgato have released EyeTV 3.

I haven't posted on my blog for a few months now, as my spare time has been tied up on a super-secret project involving Flash (well, Flex), Papervision3D, Box2D and what for me is some really heavy duty math.  However, after what I found to be a particularly disappointing MWSF 2008 keynote, I noticed EyeTV 3 appear, and I must say, it's worth a mention.  Slamming down &#163;30 was a no-brainer... far more palatable than the &#163;60 they charged for the EyeTV 1 to 2 upgrade.
I also noticed while writing this review that Elgato's 404 page gives out a 10% discount code... Nifty.  Only wish I'd found it a couple of hours ago.
In short, there are things I still don't like about EyeTV, and things I haven't really tried yet.  On the other hand, there are a few features in V.3 that make up for all of that.  In fact, a good chunk of the wishlist in my previous post is now done:

"Smart Playlists" and "Smart Recording Schedules".  I can now set up automated record lists based on complex criteria.
A smarter search engine.  Done.  They've got a full set of criteria there, with an all/any system.
Tuner and recording sharing over Bonjour.  Shared Libraries appear on the sidebar, and the system seems to work well.  I can easily watch recordings on my Mac Mini from my Laptop with little or no delay.  It even works when EyeTV.app isn't running on the serving machine, thanks to a background daemon.  Of course, it'd be far nicer if both machines' tuners could be fully and automatically scheduled and controlled from a single interface, but hey, you can't have everything.

While they've given EyeTV a patchy makeover and added some other minor features, these three alone justify the upgrade for me.
Unfortunately, the other features on my wishlist don't seem to be there yet.  PDC, in particular, would be nice.  Apparently, the Freeview Playback standard supports something similar to PDC, but I see no evidence of it in EyeTV.  This really would have come in handy a couple of days ago, as the popular and eagerly-awaited new Louis Theroux documentary started 15 minutes late thanks to a bunch of fat "sportsmen" throwing darts about.
The other one I'd still really like is a "close" button on the pop-up controller.  It's still far too enthusiastic, popping up at the slightest provocation, and assuming any accidental keypress is a request to change channel randomly.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2008/01/16/eyetv-3/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
	
		<series:name><![CDATA[Elgato EyeTV reviews]]></series:name>
	</item>
		<item>
		<title>O2 Cocoon: Review, Part 3: Wrapping Up</title>
		<link>http://gidden.net/tom/2007/09/01/o2-cocoon-review-3/</link>
		<comments>http://gidden.net/tom/2007/09/01/o2-cocoon-review-3/#comments</comments>
		<pubDate>Sat, 01 Sep 2007 11:50:03 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Reviews]]></category>
		<category><![CDATA[3g]]></category>
		<category><![CDATA[camera-phone]]></category>
		<category><![CDATA[cameraphone]]></category>
		<category><![CDATA[Cellphone]]></category>
		<category><![CDATA[cellular]]></category>
		<category><![CDATA[Cocoon]]></category>
		<category><![CDATA[gsm]]></category>
		<category><![CDATA[Hands-On]]></category>
		<category><![CDATA[isync]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[mobile]]></category>
		<category><![CDATA[Mobile-phone]]></category>
		<category><![CDATA[mobile-phones]]></category>
		<category><![CDATA[music-phone]]></category>
		<category><![CDATA[musicphone]]></category>
		<category><![CDATA[O2]]></category>
		<category><![CDATA[O2 Cocoon: in-depth Review]]></category>
		<category><![CDATA[Review]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/09/01/o2-cocoon-review-3/</guid>
		<description><![CDATA[I've been using the O2 Cocoon as my main phone for a few weeks now, and I'm fairly happy with it.  After covering the design of the phone and the music features previously, I'll wrap up by covering the rest of the features.

As I said before, it's a good phone.  In particular, the One Big Distinguishing Feature -- the external display -- does work quite well.  I do, however, with they'd put a "clock" button on the outside.  I haven't worn a watch in about ten years, since I got a mobile with a built-in clock (yes, those used to exist).  As a result, I use my mobile like a pocket watch.  In fact, I probably use my phone more as a watch than as a phone.
On the plus side, the nice big external display works well... except in sunlight as mentioned in Part 1.  However, it's not always on:  it only stays lit for a few seconds, unless it's externally powered.  So, to check the time you have to open the phone, which defeats the purpose of the external display.  The alternative is to fiddle with the music controls, which almost works:  the clock appears after scrolling messages like, "HELLO, I LOVE YOU - THE DOORS - PAUSED".  A simple "check time" button would be more useful.
The firmware is fairly nondescript.  The user interface is basic but clean.  It's not quite as well laid out as the Nokia or Sony Ericsson firmware, but I didn't find any major blunders.
I was discussing the LG Shine with my sister the other day.  One thing she mentioned was the number of button presses to send a text message.  With her old Sony Ericsson, it was just a few presses (plus the message itself), whereas the LG Shine had a minimum of eight or so.  This was a sign of poor UI design, I guess.  I remember that one of the reasons Boo.com failed in the old days was the ridiculously long and confusing path to a successful purchase.  Same with the Shine.
I'm not sure what procedural criteria she used for testing this, but the Cocoon seems to be slightly better than the Shine in this regard.  There were a few bloopers, such as the slightly silly configuration of the shortcut bar.  Like many other new phones, the Cocoon allows you to set up a few shortcuts on the main screen to commonly used functions.  In my opinion, a well laid-out UI shouldn't need this capability, but hey.  Well, in their wisdom, O2 have chosen an odd choice of shortcuts to start with, such as another link to the music player, as if the four buttons down the side weren't enough.
There's also no easy link to the camera.  Some phones, such as my old Nokia 6680, have an external lens cover, which activates the camera function when opened.  Others, such as the Shine and the Nokia 6280 I was using before the Cocoon, have an external shutter button which activates when held down.
The Cocoon has no such button.  Instead, it's five or six clicks through the main menu.
Suffice to say, one of the first things I did was to change the shortcuts.
On the subject of the camera, I must say I think the Cocoon's 2MP camera is not too shabby at all.  It's still just a tiny little chip like other normal phone cameras, but it doesn't seem to suffer from the "stripey graininess" that seemed to affect most mobile phone cameras I've used.  There's some chromatic aberration, the camera controls are a bit clunky, the shutter is a bit slow, and it's all a little bit soft and blurry, but other than that it does the job.
That sums up the Cocoon quite well.  It does the job.  It could do the job better, but it doesn't make me want to violently turn it into little white and black pieces, and believe me, some phones will do that to you.
So, what's the big thing I really don't like about it?
Mac compatibility
The Getting Started guide that comes with the Cocoon is quite upbeat:  "O2 Cocoon is also Mac friendly", it says.  Bollocks.
What they mean is that you can mount the phone as a USB drive, and then use the Finder to drag music files to/from it.  Later on in the book, they reveal that you need third-party software to use iTunes to manage it, and "Unfortunately it is not possible to synchronise calendar or contacts."
This is a big problem for me.   I damned the LG Shine for lack of Mac support, and I must do the same for Cocoon.  Both of these phones are oriented towards posers, especially the white and curvy Cocoon.  So why alienate the biggest gadget posers of all, us Mac users?
You see, one very nice feature of Mac OS X is that it comes with iSync:  a framework for data syncronisation between the Mac and devices such as mobile phones.  Out of the box it supports a fairly wide range of phones, and although Apple can be quite slow at updating that list, when it works, it really does work.
With a few clicks, I can have my address book and iCal calendar synched with my phone, and vice versa.  No software installation is necessary, and all it requires is pairing the phone over Bluetooth.
This capability alone has brought sales to Apple, as more than one person has seen me sync my phone and iPod and wanted that ease-of-use enough to go down to Apple Regent Street and buy an iBook.
For PC users, an third-party utility is necessary.  In my experience, the quality of this software ranges from terrible to bearable, but never quite as good as iSync.  I've had the embarrassing misfortune of wrecking a client's Windows installation trying to get such software running on their PC.
The Cocoon allegedly comes with its own software suite which includes this functionality.  I'm not really in a position to test or evaluate Windows software, so I can't tell you how good it is.
What I can tell you is that a manufacturer can add support for their phone to iSync merely by creating a configuration file or two.  They just need to specify the particular oddities and specifics of their firmware to iSync, and then it takes care of the rest.
This means that when a new Nokia, Motorola or Sony Ericsson phone is released, there's a good chance that an enterprising hacker can whip together a usable config file in a few minutes, just by finding a similar supported phone and tweaking the file.
Since iSync doesn't support any LG or Pantech phones, this quick hack route isn't possible for the phones I've reviewed.  However, with enough technical information on the Cocoon, I reckon a fully functional driver could be put together in a week or so.  Certainly far less time than was spent on the PC Suite.
I contacted O2 about this issue, and got the following response:

Although O2 are committed to Mac support we are unable to support iSync at this moment in time. However it is possible for Mac users to still update and change their music by dragging and dropping files to and from the phone.
We are actively investigating iSync support for both Cocoon and all future O2 branded devices.

This is admittedly better than the lack of reply to a similar query I sent to LG, but until I see working iSync support, I'm not completely convinced.
In the meantime, I'm stuck with transferring my contacts via the USIM from my old phone, so they're all truncated, divided and generally munged.
I've made purchase decisions based solely on iSync compatibility (or lack thereof) before.  I didn't buy my Nokia 6680 until there was iSync support for it.  Looking at the web stats for my LG Shine review I can tell you that I'm not alone in thinking this is important.  There are enough hits coming from Google searches such as "LG Shine isync", "LG Shine Mac" and "shine phone isync doesn't work" for me to assume that someone would be fairly popular if they hacked such a file together for the Shine, and I reckon the same would be true for the Cocoon.
So, hurry up, O2.  Demand iSync compatibility from your OEM, or at least demand the technical information necessary for third-parties to add it.  Talk to Apple and see how they can help.
Anyway, on that note, I'll wrap up.
I'm going to carry on using the Cocoon.  All things considered, it's an above average phone with some very useful features.  I still don't think it's as good as they think it is, but it's a darn sight better than some of the other phones I've used in recent years.  When I get around to it, I'll try shoehorning my contacts into it, using one-by-one Bluetooth if necessary.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/09/01/o2-cocoon-review-3/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
	
		<series:name><![CDATA[O2 Cocoon: in-depth Review]]></series:name>
	</item>
		<item>
		<title>iPhoto, Flickr and EXIF munging using Perl</title>
		<link>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</link>
		<comments>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/#comments</comments>
		<pubDate>Wed, 27 Dec 2006 18:21:00 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[albumdata.xml]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[cocoa]]></category>
		<category><![CDATA[exif]]></category>
		<category><![CDATA[flickr]]></category>
		<category><![CDATA[flickr::api]]></category>
		<category><![CDATA[geocoding]]></category>
		<category><![CDATA[geotag]]></category>
		<category><![CDATA[geotagging]]></category>
		<category><![CDATA[iphoto]]></category>
		<category><![CDATA[iptc]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[mac::iphoto]]></category>
		<category><![CDATA[metadata]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[PerlObjCBridge]]></category>
		<category><![CDATA[picasa]]></category>
		<category><![CDATA[scripting]]></category>
		<category><![CDATA[xmp]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</guid>
		<description><![CDATA[EXIF/IPTC/XMP tagging of GPS coordinates, folksonomy tags, and other goodness is a nice idea, but unfortunately, iPhoto and Flickr don't play too well together.  Couple this with the fact that any decent support those products now have is not included for photos already imported into them.  So, here are some notes resulting from some experimentation, along with the Perl code I wrote along the way.

(Note: for the rest of this post, I'll refer to all metadata stored in the image file itself such as EXIF, IPTC, XMP, etc. as "EXIF" data.  This isn't strictly correct.  However, using the term "metadata" could be confused with such data held in other files, such as iPhoto's own database.)
For Christmas, my dad bought my mum a decent photo printer: the Canon PIXMA iP5200R.  Very nice piece of kit, with good printouts, and most importantly, easy setup, with no CUPS and Windows -v- Mac issues.  Anyway, as an upshot of this, my dad wants some of my photos for building a Picasa library for her to print stuff from.  Specifically, the photos from the Caribbean holiday we had earlier in the year.
I've been playing with Picasa a bit, and I must say I love it.  It's what iPhoto should be.  It's a good deal faster for a start.  That's comparing my iBook G4 1GHz against my mum's Compaq Deskpro Pentium III 733MHz, which is a few years older.  Secondly, it doesn't use a horrible non-scalable monolithic database like iPhoto does.  Thirdly, it seems to deal with metadata a bit more sensibly.
On the downside, neither iPhoto or Picasa handle collaboration functions very well.  Both have publishing functions, and iPhoto has a read-only "sharing" function, but I mean the true sharing of photo libraries.  My mum and dad have separate computers, but they share a camera, so it would be incredibly useful to have a shared photo library which either could use.  On this count, Picasa wins slightly, because although it has no true sharing ability, there doesn't seem to be anything wrong with two copies of Picasa working on the same directory on a shared drive.  I'm not sure how it would handle conflicts though, due to the lack of locking.  For now, I'll advise my parents not to run it at the same time.
I usually manage all of my photos in iPhoto.  However, due to the lack of decent keywording and other metadata in iPhoto, I ended up adding a lot of metadata in Flickr instead.  As a result, my iPhoto library is woefully out-of-date with my Flickr library, even though it's far more complete as I only upload a subset of my photos to Flickr.  I specifically want to extract Flickr tags back into the files themselves, and ideally rip the Geotagging information I added within Flickr.
While iPhoto is drastically improved by Keyword Assistant, it doesn't store the keywords (read: tags) in EXIF form, but in its own database.  During this investigation I discovered that iPhoto does import keywords from EXIF, and also Geotagging info.  The fact that it doesn't manage EXIF is a fairly annoying flaw, and one that I hope they'll be fixing.  I've heard that Microsoft Vista now does sensible things with EXIF.  iPhoto is, quite frankly, falling far behind other solutions at this point, and I hope next month will bring a new iLife with an improved iPhoto.
So, I had a good look around the 'net for some utilities to try to clear up this mess.  I've had a play with things like Cal Henderson's Flickr::API and Dmytro Kovalov's Mac::iPhoto before, and they're not particularly mature.  Incidentally, Mac::iPhoto also seems currently broken.
Others have attempted using Applescripts.  The ones I found around the 'net are far too slow to cope with the ~8000 photo collection I have.  This is probably due to the sucky design and/or implementation of Apple Events in MacOS.
Instead, I've had a play with PerlObjCBridge, or whatever Apple's calling it.  In Perl, it's "use Foundation;".  This gives access to the Cocoa API within OS X, which I figure is probably the fastest way to manipulate Property Lists.  Since iPhoto stores at least a backup of the database in XML form (specifically Property List form) as "AlbumData.xml", we can use this to cross-reference the data.
The most critical link between my Flickr and iPhoto collection is missing.  This would be a link between each individual photo and its alter ego in the two different collections.  Since filenames aren't necessarily complete or preserved by either iPhoto or Flickr, this is relatively difficult to establish.
I've found that a reasonably good connection is between image creation time/dates.  By matching the EXIF timestamp data within the file stored by iPhoto with the EXIF data extracted from Flickr, you can get a reasonably good correlation.  At this point, it would be a nice idea to shove the Flickr URL for the image into the local EXIF data and get iPhoto to read it.  From then on, there would be an established link.
Well, I got about as far as adding the URL, tags and geocoding to the image, but I gave up when it came to getting iPhoto to read it.  There is a relatively obscure "rebuild" function in iPhoto, triggered by holding down Cmd and Opt while starting iPhoto.  This allows rebuilding of thumbnails and the binary databases (presumably) from the XML.  Unfortunately, it doesn't seem to reread the images for new metadata.  I think this would require actual modification of the AlbumData.xml file to work, which sounds like a far bigger job.
In the meantime, this proves that such a script is feasible, albeit painful.  At the moment, this is a run-once script, so it's not much use for regular usage.
SOURCE CODE:  I am supplying this code freely with the understanding that there is no warranty or guarantee.  Also, I'll go as far as to say that incorrect usage could quite easily delete your photos, destroy your Flickr account, upset Flickr, and kill your pets.  DO NOT USE THIS CODE UNLESS YOU UNDERSTAND IT COMPLETELY AND ARE WILLING TO TAKE RESPONSIBILITY FOR ANYTHING GOING WRONG.  For more details, read the README file.
The most recent version can be obtained from my Subversion repository: iphoto_flickr_exif_munge/.
I also apologise for the quality of some of the code.  It's far more experimental than I'd usually want to release, but I think it might be of use to someone like me in a similar situation.  Rather than just throwing it into the depths of my hard drive and forgetting it, I figure it's probably worth blogging.
My conclusion to all of this is that I really need to get my iBook replaced with something good enough to run Aperture or Lightroom, and then reimport the whole bloody lot.  Painful, to say the least.  I'm also hoping that Google get around to writing Picasa for the Mac.  I think I'd prefer it in the long term.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Mac Flight Tracker widget timezone bug</title>
		<link>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/</link>
		<comments>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/#comments</comments>
		<pubDate>Thu, 10 Aug 2006 20:54:07 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[bdt]]></category>
		<category><![CDATA[bst]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[dashboard]]></category>
		<category><![CDATA[flight-tracker]]></category>
		<category><![CDATA[flighttracker]]></category>
		<category><![CDATA[javascript]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[Mac-OS]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[MacOS]]></category>
		<category><![CDATA[nsdate]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[os_x]]></category>
		<category><![CDATA[tiger]]></category>
		<category><![CDATA[timezone]]></category>
		<category><![CDATA[widget]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/</guid>
		<description><![CDATA[The Flight Tracker dashboard widget that comes with Mac OS X 10.4 (Tiger) seems to have a fairly major bug.  However, this bug seems to be the result of something quite obscure to do with timezones, and it only seems to manifest itself in the UK during the summer.

I've noticed this problem a few times:  specifically whenever any one of my close friends or family members flies anywhere.  This time, my mother is on her way back from San Diego to Bristol via Newark.  Thanks to the incredibly annoying terrorist attack attempt today, my dad and I were understandably concerned about flight delays, so I pulled up the Flight Tracker.  Unfortunately, the information seems completely wrong.
Turns out, the minutes are right but the hours don't relate to any of the relevant timezones.
Anyway, a little background.  Here in the UK, we have two main time scenarios:  firstly GMT, which is for all intents and purposes, UTC.  We also use BST:  "British Summer Time" which is UTC+1h, and kicks in for archaic agrarian reasons and the "Think of the children!" brigade who are convinced it'll stop traffic accidents.
While the rest of OS X seems okay and correctly uses BST, Apple's Mail.app has always strangely listed incoming mail as being sent relative to "BDT", which comes out as "British Daylight Time", which is fairly meaningless as there's no such thing.  The times are correct, but they just have the wrong abbreviation afterwards.  On researching it, this seems to be the result of bad data from the Unicode people which might have made its way into NSDate.  Anyway, it's usually just a cosmetic thing, and of little or no consequence.
I believe, however, that it's the cause of the Flight Tracker widget's problems.  To test this, I altered the widget to display the timezone, by replacing the bit in FlightTracker.js, in function formatDateForDisplay() that says
var timeStr = date.toLocaleTimeString("short");
with
var timeStr = date.toLocaleTimeString("long");
This reveals that the times are supposedly in "BDT".  I believe this might be the problem.  I think something is reinterpreting this as "Brazilian Daylight Time", which would explain the weird offsets.  I think JavascriptCore or something is referring to the same bad data as Mail.app, probably via NSDate.  I'm not a Safari hacker, and I haven't really investigated that far, so I'm not sure where the problem is.
Looking a bit deeper into FlightTracker.js, I'm not really surprised there's a problem.  The timezone calculation code is fairly messy, with comments such as:
// We're going to be stupid and hard coded about parsing the server provided date strings for now
// ??? for some reason parseInt returns 0 on this but parsefloat works ???
and
// here we do proper handling of the timezone offsets.
// We enter everything in pretending it's UTC time
// and then we convert it to miliseconds since 1970,
// add the timezone offset in miliseconds to it
// and then set this as the new UTC time
There seems to be some string hacking going on at several places to decode the data sent from FlyteComm.  The original data is reasonably well structured, with the timezone offsets being given correctly as -0700 and +0100, which presumably indicate that the times are given as local times of the departure/arrival locations, as per normal for the airline industry.
I'm not completely sure what's going on, as I'm not really set up to debug someone else's widget, especially one with weird custom controls, and barely any code comments.  It's obvious to me that the widget isn't particularly well written, and is one of those things that "just works".  It was probably hacked up for fun by a Dashboard developer, and then fasttracked to the nearest Steve Jobs keynote rehearsal.  As Steve Jobs's Dashboard demos tend to be done at MWSF and WWDC, I doubt this problem has ever really been seen at Apple.  I bet if it was a problem with Pacific Daylight Time being misinterpreted, it'd be fixed immediately!  I've done a little bit of googling, and it looks like the BDT bug has already been submitted to Apple (several times), and it's still there.
When I get a chance, I may try to debug this one further, and perhaps rewrite FlightTracker's timezone code properly using the correct offsets rather than performing nasty magic using getLocaleTimeString().
What I would prefer is that the timezone of each time is given next to the time.  Ideally, they should toggle-on-click or slowly fade between local times (to the flight) and local times to the machine, and possibly relative times ("1 hour ago", "in 53 minutes", etc.)  That would make the tool a lot more intuitive anyway.  I'd rather not reinvent the whole widget, as in all other ways, the widget's really not too bad.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/feed/</wfw:commentRss>
		<slash:comments>18</slash:comments>
		</item>
		<item>
		<title>X11 Colors list for Mac OS X</title>
		<link>http://gidden.net/tom/2006/08/04/x11-color-list-for-macosx/</link>
		<comments>http://gidden.net/tom/2006/08/04/x11-color-list-for-macosx/#comments</comments>
		<pubDate>Fri, 04 Aug 2006 21:29:38 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[clr]]></category>
		<category><![CDATA[colors]]></category>
		<category><![CDATA[colours]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[Mac-OS]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[MacOS]]></category>
		<category><![CDATA[NSColorList]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[palette]]></category>
		<category><![CDATA[PerlObjCBridge]]></category>
		<category><![CDATA[rgb]]></category>
		<category><![CDATA[x11]]></category>
		<category><![CDATA[x11-colors]]></category>
		<category><![CDATA[x11-colours]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/08/04/x11-color-list-for-macosx/</guid>
		<description><![CDATA[A friend of mine is a recent newbie Mac user, after finally succumbing to the shiny white lure of the MacBook.  As an expert Unix user, he was missing the old X11 colours list, because he can't have his terminal set up with a horrible shade of puce without having to work out the RGB values for it.

Christopher Holland has already created an OS X color list for the Resene color list which is allegedly used on many X11 windowing systems, but to be honest, I haven't encountered it before.  I last used an SGI in about 1997, and I must confess I never looked at the color selector.  It also didn't seem to include the specific wretched tincture my friend wanted.
So, rather than taking the easy route and just picking the closest match from the Apple crayons, we had to grep /usr/X11R6/lib/X11/rgb.txt instead.
To eliminate the possibility of this nightmare operation having to be done again when he finally comes to his senses and picks a normal color, I hacked together a quick bit of code to create a .clr file.
Just use the "Open..." doodah in any colour selector in Mac OS X.  It should automatically copy the file into your user's Library/Colors.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/08/04/x11-color-list-for-macosx/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>loginwindow.plist Is My Enemy</title>
		<link>http://gidden.net/tom/2006/07/13/loginwindow-plist-is-my-enemy/</link>
		<comments>http://gidden.net/tom/2006/07/13/loginwindow-plist-is-my-enemy/#comments</comments>
		<pubDate>Thu, 13 Jul 2006 12:40:40 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[annoying]]></category>
		<category><![CDATA[daemon]]></category>
		<category><![CDATA[launchd]]></category>
		<category><![CDATA[loginwindow]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[os_x]]></category>
		<category><![CDATA[preferences]]></category>
		<category><![CDATA[stupid]]></category>
		<category><![CDATA[tiger]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/07/13/loginwindow-plist-is-my-enemy/</guid>
		<description><![CDATA[I've been trying to track down a few annoying apps that start up on my iBook and can't be found in any of the usual places.  I checked the normal places:  the Login Items for my user, LaunchAgents and LaunchDaemons, and a few other places... I forgot to check loginwindow.plist.

The specific program in question is /Library/CFMSupport/CNQL2410_ButtonManager.app, which is a little daemon that monitors the buttons of my father's scanner that I rarely borrow.  Also, the Version Cue stuff in Adobe CS2 can sit there rather unhelpfully... even though I uninstalled CS2 since leaving my last workplace.  (My rant against Installer VISE is a separate issue)
So, the solution is to trash /Library/Preferences/loginwindow.plist.  If you ask me, this is a particularly stupid place for startup items to live.  I understand that there has to be a place for startup items that aren't dependent on a user logging in, but it damn well shouldn't be a Preferences file.  Of course, the solution to this is probably launchd, but the problem is with this idioty little apps that are written by people who obviously haven't read any of Apple's development guidelines.
Incidentally, has anyone ever found a scanner or printer that has decent, HID-compliant driver software for Mac?  I don't think such a thing exists.  They're all so idiosyncratic and lame, and they completely fail to interface with the OS's built-in facilities.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/07/13/loginwindow-plist-is-my-enemy/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

