I’ve been out of town for the past week and a bit so I’ve a fairly heavy backlog of email and support requests. If you sent me email in the last week, don’t worry – I’ll get to it and get back to you. Might take a day or two tho’…
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…
Every photographer I’ve met has a photographic skill they know lags well behind the rest of their skillset. Me? It’s flash photography. In short, I suck. I was reminded of this a few weeks back when I shot some portraits for a friend. Nothing fancy but awkward lighting. We managed to salvage a few shots but it could have been so much better.
I’ve never been comfortable using flashes and have usually hated the results that I’ve gotten from them. In fact, I’ve gone to ridiculous lengths not to use a flash when it would have made my life so much easier. I’ve played with larger, studio flash setups from time to time (and been happier with the results) but they’re just not practical for a lot of the photography I find myself doing.
However, I stumbled across a website a few weeks ago that totally changed my outlook on this black art. Strobist is dedicated to flash photography using lightweight, very portable equipment. After reading through the Strobist 101 section and looking at the results, I was completely sold.
If you’re a flash-o-phobe like me, I strongly recommend checking out the Strobist website and Flickr photostream. Hopefully you’ll have the same “ding!” bell go off that I did…
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 saw this post on the Inside Lightroom blog and replied to it about using Lightroom to generate PDF contact sheets and thought I’d mention a bit more about it.
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…
Update
At the start of 2006, I posted about the workflow I was using for processing images. As you can imagine, it’s changed significantly over the last 18 months as tools like Lightroom, Aperture, Bridge and Photoshop CS3 have appeared. As folks still seem to look at the Workflow 2.0 post I wrote, I thought it was time to update with what I was currently doing.
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…
Although I haven’t posted much, if anything, on Cocoa programming I thought I’d post a bit more over the next few months. I’ve been coding in Cocoa for quite a few years now and it is, by far, the most productive application coding environment I’ve ever worked in. Unfortunately, the scope of Cocoa is huge and, if it wasn’t for other Cocoa programmers posting hints, notes and tips, I’d still be scratching my head about topics like drag-and-drop weirdness with NSTokenField bindings (more on this in a later post).
So this is to try to repay the favor to other coders who’ve struggled with the same things I have. And where better to start than one of the uglier problems that many programmers run in to; subclassing class clusters. The Cocoa designers, in their infinite wisdom, decided to make a few of the core Cocoa classes based on a class cluster and not concrete. This makes them awkward to try to subclass as you have to work out all of the primitive methods and provide support for them in the subclass.
Most folks end up giving up in disgust and wrapping things like NSMutableDictionary. However, once in a while, you really, really, really need to subclass it. In my case, I wanted a basic class that I could use in RapidAlbum that would call a delegate when an object in the dictionary was added or changed (so that I could flag a page export). However, I really wanted a dictionary interface as I wanted to be able to leverage all the existing NSDictionary methods (like dictionaryFromDictionary:) as the whole point is to avoid writing more code.
The trick here is to catch setObject:forKey: and removeObject:forKey: and add a delegate call. Note that if you could easily register a wildcard key-value observer for a container class that tracked all key/object changes in the class, then this would be unnecessary. That’s an expletive-laden rant for another day.
There’s a few pointers out there as to how to subclass NSMutableDictionary but nothing that really covers all of it. So, without further ado, here’s the approach I took.
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.