This is another minor update to fix some bugs. In restructuring some of the internals, I broke the media ordering code so that images were listed in the order they’d been added to the album, not in the required sort order. This update fixes that problem.

I’ve also added an example template to show how to link images with geocoding in their metadata to Google Maps.

I abandoned a complete rewrite of the plugin before Christmas, as the plugin was growing in scale and looking like becoming a bit of a monster. My goal with RapidAlbum is to make it easier to use – the rewrite looked like it’d make it a lot harder to support, which is most decidedly a non-goal. A lot of the complexity was centered around the support for image warehousing, which turns out to be quite complicated to make suitably robust.

When you talk about support load on free software, many users will kindly say “but I’ll pay for support!”. I’ve been lucky to have a lot of users who like RapidAlbum enough to offer to pay for it. That’s very kind but I actually have a day job that I enjoy – for the moment, Mac software is a hobby rather than a career. The support load that RapidAlbum presents has to be kept somewhat in check.

So what happens now? Well, my short term goal is to produce regular releases. I’m going to be tackling small problems and feature requests in RapidAlbum and fixing them for a while. I’m also going to be reworking the UI to get it closer to what I actually want.

The big goal in the near future is a change to the way templates work. I’m planning on bundling all the extra templates inside the plugin (so they’re installed automatically). I’ll also be culling out some of the older templates. One of the reasons for doing this so that I can add a better interface for template options – I’d like to be able to offer an easy way to control features in prettyPhoto, Galleria, et al without having to manually edit the template (altho’ I’ll still allow that).

I’d actually written a fair bit of this code for the rewrite I abandoned. I’ll be reworking those changes into a release in the next month or two.

You can download the new release from my software page.

Looks like my WordPress RSS2 setup wasn’t conforming to the tighter set of W3 rules that Apple are using for Safari and Mail subscriptions. I’ve rejigged the setup so that it sucks much, much less.

The feed is now

http://www.smackie.org/notes/feed/rss2/

Please use this feed if you’re using an older one with “wordpress” in the URL. This’ll be the feed URL going forward.

Thanks to everyone who dropped me a note or comment about this. Sorry for the inconvenience…

Cheers!

Scott…

A problem area for the current RapidAlbum code is image handling. Right now, when RapidAlbum generates scaled images (such as thumbnails and smaller main images), it generates them to a cache directory in the user library. This sounded like a good idea at the time but it’s led to some subtle and awkward bugs.

The image handling for RapidAlbum 2 is going to work like this -

• Thumbnails and sized images will be stored in the RapidWeaver document sandwich. I’m going to offer the ability to store the original image in the document sandwich too so that folks who don’t want to keep the original after they publish will have a backup. The current behavior, whilst very useful for a lot of folks, has caught a few users out. You’ll be able to change whether a local copy is kept or not as an album setting.

• Original files will be tracked better on disk. Right now, when you move original images around, RapidAlbum gets confused. I’ll be tracking image paths a lot better in the new code.

• Local copies of scaled images offers the potential ability to allow image warehousing. This is something I’m definitely working on. Whether it makes the first 2.0 release or not depends on how easy it is to add network browsing but these changes open up this possibility.

• Images will be scaled at import and when the parameters change. Right now, they’re scaled on publish/export which causes all sorts of problems during generation (as I need some of the thumbnail and scaled image info before building the actual HTML for the pages).

All of these changes should make RapidAlbum a lot more reliable and robust for image management.

Cheers!

Scott…

However, I needed to update the development environment for RapidAlbum so that it would work with the RealMac AddOns site, bring it up to date with both the newer RapidWeaver SDK interface and Apple developer tools. I also had a load of outstanding bug reports and simple tweaks that folks had asked for.

And, let’s face it, it doesn’t hurt for me to release some code to prove that I’m actually working on this!

As always for plugin updates, backup your RapidWeaver documents and don’t update in the middle of a big site design. This is a minor update and I’ve tested it a fair bit on RapidWeaver 4 + 5 but weird stuff can still happen. Caveat Emptor.

So, what’s new? Well, you can see the list on the Release Notes page.

There are two new templates in the “extra” template folder in the disk image. I’ve added a very basic template based on Galleria, which is quite nice. And I’ve also added a Slimbox2 template, which gives the same look as Slimbox but is based on JQuery.

Note that both of these templates will work with RapidAlbum 1.0.3 as well, if you don’t want to risk changing your RapidAlbum plugin at the moment.

As always, drop me a note if you have problems, questions or just want to say “hi”. You can use the new support interface to get hold of me.

Cheers!

Scott…

p.s. I just realized I left Galleria out of the build. Doh! You can download a copy here for the moment…

I expect to release RapidAlbum 1.1 later this week. It’s not a massive change from 1.0.3 but it’s changed a fair bit under the covers in order to make it easier for me to continue working on the next major release.

Cheers!

Scott…

I’ve just finished bringing my latest private builds of RapidAlbum up to compatibility with the latest Apple toolchains and SDKs. This involves reworking code to remove outdated or depreciated techniques. The problem here is that it’s going to be tricky to support the PowerPC build going forward. Now, I can do it but it does affect how I approach RapidAlbum development.

If you’re actively using RapidAlbum on a G4 or G5 system, could you post a reply on this discussion?

RapidAlbum on PowerPC Systems

I’m trying to gauge how many folks still need a PowerPC version of RapidAlbum.

Cheers!

Scott…

I’d decided to supply some templates as an example of what you could do with RapidAlbum and documented the plugin template builder support a bit so that other, adventurous folks could use it to build their own template tools. I’d never really intended them to be anything other than examples.

However, it’s pretty clear from my inbox that folks are using the templates as-is and are looking for versions of the templates that are updated to the latest versions of the Javascript tools. That’s not really what I had in mind originally but it’s not an unreasonable request given that the existing examples are quite a few years old now.

You can download a fresh version of templates here. I’ve updated all of the Javascript-based templates that have new versions available and added some other templates (Pretty Photo) that I made available a while back. I’ve also added a new template, called MooFlow which uses the MooFlow Javascript support to build a coverflow-like gallery. It’s not perfect but I hope it illustrates what you can still do with RapidAlbum, old and creaky as it now is.

I decided over the summer to start work on RapidAlbum again. I’ve already got the basics for RapidAlbum 2.0 written – it’s a complete rewrite for the latest RapidWeaver versions and Snow Leopard. I don’t have a release date for it yet but I’ll post more as it takes shape.