Archive for the ‘Software’ Category

RapidAlbum Discontinued

Thursday, November 15th, 2012


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.


RapidAlbum 1.2.4

Saturday, January 21st, 2012

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.

RapidAlbum 1.2.3

Wednesday, January 11th, 2012

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.

RapidAlbum 1.2.2

Thursday, January 5th, 2012

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.

Images and RapidAlbum 2

Wednesday, May 25th, 2011

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.



RapidAlbum 1.1

Thursday, May 19th, 2011

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…

Updated Website

Monday, May 16th, 2011

I’ve just updated 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.



PowerPC support for RapidAlbum

Saturday, February 26th, 2011

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?

RapidAlbum on PowerPC Systems

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



RapidAlbum update and new templates

Wednesday, November 17th, 2010

My original goal with RapidAlbum was to solve a problem I had with creating custom web albums for a site I was building in RapidWeaver. After a few months tweaking and developing the plugin, I realized I could use the basic support to build pages that used existing Javascript and flash photo album tools (like SlimBox and SmoothGallery). This seemed like a cool idea so I added support for album templates.

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.

RapidAlbum Update

Thursday, April 29th, 2010

Last week, I posted a note on the RapidWeaver forums saying that I was thinking about making RapidAlbum open source. This is primarily because I don’t have a lot of time to maintain it at the moment and wondered if making it open source might not be a better way to tackle the problem. I write software for a living and only have so much time in the day to design cool stuff. And, more importantly, I only have so much space in my head to hold designs at any one time.

RapidAlbum is a reasonably large RapidWeaver plug-in so it takes a bit of time to come up to speed each time I step back into it.

Unfortunately, I haven’t had any real interest in RapidAlbum as an open source project. This leaves me in somewhat of a dilemma. On one hand, folks are still using it and expecting me to support it (at least a bit). On the other hand, the code is getting a bit stale and needs to be updated to the latest RapidWeaver 4.X APIs at the very least (as it still uses the old RapidWeaver 3.X APIs).

If you’re interested in RapidAlbum as an open source project, let me know. You can drop me a note via the contact page.