It’s time to acknowledge what is probably obvious from the lack of action in support forum. I just don’t have the time to maintain or support RapidAlbum these days. My work and personal commitments make it impossible to dedicate enough time to supporting it adequately, let alone getting time to work on new features.
This is obviously frustrating and disappointing for those of you who use RapidAlbum. It’s frustrating and disappointing for me too. However, I can’t continue to apologize for the lack of support and updates when my work and travel schedule over the next 6 months makes it very unlikely that I’ll be able to spend anywhere near the time I need to on RapidAlbum.
The email support load for RapidAlbum has risen steadily over the past year. Sadly, the majority of the problems aren’t really to do with RapidAlbum but rather to do with layout issues or conflicts with 3rd party templates. I spend a lot of my support time debugging CSS layouts. That’s a function of the fact that most RapidWeaver themes these days provide lightbox support, which often conflicts with the selected RapidAlbum template. I’m happy to look at CSS issues but, if I’m honest, it’s not really what I want to do with my limited spare time. Sadly, I’ve also seen a steady rise in abusive and flamebait support emails in the past year.
Taking all this into consideration, I’ve decided to pull the plug on RapidAlbum as an active, supported project.
I’ll leave the support forum alive for a while with a disclaimer about RapidAlbum being unsupported. I will, however, remove the software pages from the website and remove it from RapidWeaver add-ons.
I’ve just posted RapidAlbum 1.2.4 for download.
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’ve just posted RapidAlbum 1.2.3 for download. This is a minor bugfix release with some more changes for PDF files, some GPS tweaks and a build fix to allow RapidAlbum to run on 10.5 again. If you’re thinking about playing with the GPS metadata, I’d strongly urge you to run this version of RapidAlbum. I’ll be posting some support info about integrating Google Maps with RapidAlbum in a bit.
I thought it was probably worth a post explaining where I am with RapidAlbum.
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.
I’ve just release RapidAlbum 1.2.2. This version has a workaround for the problem that causes the “plugin not found” issue that seems to have plagued some users in RW5 with RapidAlbum. I’ve also fixed a few other problems and glitches.
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
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…
I’ll be posting a few notes over the next month or two about upcoming changes. I don’t really want to post too much on this as things are still in flux but I thought it’d be worth pointing out the areas that I’m rewriting completely and know will change.
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.
I’ve just released RapidAlbum 1.1 for download! Before everyone gets too excited, this release really is a bugfix and tweak release. The real changes will come in RapidAlbum 2.X, which I’m actively working on. That release will have some major changes (especially to template compatibility, image generation and the UI).
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.
p.s. I just realized I left Galleria out of the build. Doh! You can download a copy here for the moment…
I’ve just updated smackie.org to a new look. The basics are pretty much the same but there’s now email support from Tender and a great deal of rejigging. This should make it easier for me to post updates and manage RapidAlbum (and other projects). If you have any problems or find broken links, please let me know.
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.
One of the things that is tricky about supporting plugins like RapidAlbum is working out how far back to support things. It’s obviously been a few years since the last RapidAlbum release and the Apple toolchain has moved on considerably.
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?
I’m trying to gauge how many folks still need a PowerPC version of RapidAlbum.