I’ve had quite a few folks ask me recently about MetaSync. I suspect some of this is driven by the release of Office 2008 and the inclusion of Expression Media in the full package.
Funnily enough, I’ve been tinkering with MetaSync again after a long absence. Towards the end of 2007, I found myself growing dissatisfied with both Aperture and Lightroom in my current image workflow. There’s nothing that wrong with them per se, but I still use ACR in Photoshop CS3 for the bulk of my raw conversions. I did try using Lightroom for a while but I found it got really clunky when some images were offline. For big catalogs, it’s still really not an effective DAM tool at all.
The end result was that I found myself creeping back to iView MediaPro 3.1.3 - it’s not sexy but it doesn’t get in the way of my workflow, gracefully deals with offline media and is DNG-aware enough not to annoy me. It’s the least bad option, if you want to damn it with faint praise.
But of course, if I go back to MediaPro, I need to dust off my old workflow tools. One of the additions to Leopard was a scripting bridge to allow Applescript events to be generated simply from within Cocoa applications. This is an absolute plus for a tool like MetaSync, which relies on a lot of scripting to extract the metadata from MediaPro. MetaSync is currently an Applescript Studio application - adding more features than it currently has means that I either have to write a lot more Applescript (ugh) or write the new features in Cocoa and instantiate the whole thing from Applescript (bleah).
In Leopard, I get to re-write the whole thing in Cocoa. This is a Good Thing. My plan is to start working on MetaSync again fairly soon. Is there interest in making a version work with Expression Media? I can add this if there’s firm interest but I’m not going to write it on spec - I don’t use Expression Media yet (there’s nothing it does that I need).
One application that’s definitely missing from the plethora available for Mac OS X is a small, compact bug tracking tool for small software developers. I’ve used a variety of systems over the years but haven’t ever really been happy with them for personal use. I don’t want a web interface, multi-user options or integration with source control. All I want is a nice, clean database that allows me to keep track of the various problems and feature requests that users have reported. No mess, no fuss.
Because of this, I’ve been tinkering around with Bento over the past few weeks. And, with a little bit of adaptation, it looks like it might be ideal for small-scale bug tracking.
Here’s a list of active bugs and feature requests for RapidAlbum:
And here’s a detailed entry:
The theme that I’m using here is non-standard. The current selection of Bento themes is pretty horrible - it’s geared towards the sort of folks who think that Comic Sans is “cute”. However, if you open the Bento application package, it’s pretty straightforward (if you’re comfortable with a plist editor) to add a new theme that uses muted colors and a reasonable font. This limits the amount of eye bleeding that the current selection of Bento themes induces (what were they thinking?).
Bento also appears to be scriptable altho’ I haven’t started tinkering with that yet (an Automator action for parsing email messages and creating a new bug record would be ideal).
All told, it took under an hour of tweaking and configuring to get Bento set up for my bug tracking needs (and most of that was theme tweaking). That’s not bad at all.
I’ve just posted the latest minor release of RapidAlbum for download. You can pick up a copy here.
This version mainly fixes some annoying niggles and nits that users have reported. The big change is that RapidAlbum now creates empty metadata fields for all of the default IPTC and EXIF tokens if they’re not present in the image file. This means that you can edit and display information for images even if it’s not present in the original metadata - useful if you’ve got an album full of odd images.
Enjoy!
I’ve finally released a full version of RapidAlbum. The 1.0.2 release is available to download right now!
I’ll post more over the next few days about some of the changes in the final version of RapidAlbum. It’s seen some pretty large changes since the initial versions but it’s still fairly close to the original vision that I had for the plugin; a tool for building large photo websites with the minimum of extra overhead.
My thanks to all of the folks who tested and gave me feedback on RapidAlbum. I’ve still got loads of suggestions to build into RapidAlbum 2.0!
It’s been a bit over a month since I shipped the last build of RapidAlbum. Since then, we’ve had Leopard released and a couple of builds of RapidWeaver to fix various weird Leopard-related problems. Things seem to have settled down again.
I’ve cut RapidAlbum over to an XCode 3.0 project. Things went relatively smoothly but I did discover some weird translation problems when moving the old NIBs across to Interface Builder 3.0. Because of that, I’ve decided to cut a private release of RapidAlbum and ask for volunteers to test it before I release it en-masse.
It’s been tested on Tiger and Leopard, seems to be stable and fixes pretty much all the bugs that folks have reported to me (the most serious of which are related to the more complicated templates not working from within Blocks and custom file locations).
If you’re interested in testing RapidAlbum for me, send me some email via the contact page and I’ll point you at the disk image…
Cheers!
I was going to wait and cut the 1.0 release for real in a week or so. However, I added a few small new features to RapidAlbum and thought I should probably cut another minor release.
Since the first alpha build of RapidAlbum, I’ve had folks ask if I could add photo sorting to the albums. This is one of those things that is actually trickier to implement than it seems at first cut. I found myself tinkering one afternoon and realized that, due to some changes I’d made earlier, implementing sorting had actually become relatively easy. Hence the addition in the latest build.
I also fixed some fairly easy (and silly) bugs that folks had run across. I’ve broken the HTML internationalization support enough times for me to think that I need to really work on that stuff for the next build release.
Finally, I added templates for the Highslide and SmoothGallery javascript toolkits so that you can build albums based on them. I got a lot of requests for Highslide; although it’s only free for non-commercial sites, it seems to have a lot of fans and was easy to support. SmoothGallery was added because I was looking for a non-Flash slideshow. It’s actually very cool so I’m looking forward to incorporating it into this site…
I just pushed RapidAlbum 1.0RC1 for download! There are a bunch of changes in this release. As you can probably guess from the RC1 title, it’s pretty close to what I’m planning to ship for RapidAlbum 1.0.
You can grab a copy here -
I just put RapidAlbum 1.0B5 up for download
http://www.smackie.org/Software/downloads/files/RapidAlbum.dmg
This is primarily a bug-fix release, with two really stupid bugs fixed (and quite a few less stupid ones too).
RapidAlbum now generates unstyled photo pages correctly. The documentation for the RapidWeaver API was, um, non-existant for this stuff and I goofed in my interpretation of it. The end result was that if a photo page was a couple of levels deep in the page hierarchy, the css includes and breadcrumbs were AFU. It now does the right thing.
My brain took a holiday and I managed to remove a very important line of code in the image scaler setup which meant that photo pages that relied on the scaler would get thumbnail sized images. Doh! Fixed.
There’s also a bunch of small bugfixes as I start to tackle the mountain of small, but annoying, bugs I know about in RapidAlbum…
I just pushed RapidAlbum 1.0B4 up for download.
The big addition for this beta release is the ability to generate an RSS2.0 feed from an album. This is the first step to building an integrated photo album/blog tool, which would be really very nice. Next step? Smart albums that know how to aggregate other albums on the site based on some selection criteria…
I just pushed RapidAlbum 1.0B3 up for download. I did push up the 1.0B2 release yesterday but I spotted a few stupid bugs in it last night whilst I was updating my own website and decided it’d make more sense to cut a new release.
As it’s often hard to get a feel for what’s possible with a plugin, especially one that’s as essentially customizable as RapidAlbum, I’ve also put a page of examples up to illustrate the sort of layout you can achieve.