It's still that property for audio clips, but if it's a relative name, the base directory is now .jalbum/attachments/fileName/ and not .jalbum/audioClips. If you instead rely on the "audioClipPath" variable, then you get the correct path to the audio clip, as reachable from within the album.

There is also the new Attachments API that will give you the full original path to an attachment, which is ao.getAttachments().get(Attachments.Type.AUDIO) or ao.getAttachments().get(Attachments.Type.IMAGE)


We're at least paving the way for this. Currently you can attach an image to an image. Only one will be processed, but as you can access the original as well, then you have access to both.

I'll have to mull that over, as well. I guess the question is, why would a user attach a JPG to a JPG (or other image type)? And what would that mean about how they would want it to be handled?

For use as an alternate image on a page, you might want both the primary and linked images to be scaled. You might want to be able edit both! That gets pretty byzantine, and only one skin currently supports it.

But turning to the rest of the skins, the only use that comes immediately to mind is for a pano, where you'd want it to use the linked image as the thumbnail, and the primary for the slide. Would you want the primary to be scaled? Would you want to be able to edit it? In the case of a pano primary, the answer might be "no" to both questions. Should the core treat the primary like a GIF, automatically tagging it as "use original?"

Needs some speculation, so we don't paint ourselves into a corner.

Now fixed. (b17)


Do you only want the thumbnail to be affected? The main purpose of this feature will likely be to have icons replaced by images. For such cases you'll likely not want to see the icon when entering edit mode

I guess the correct behaviour would be to generate the thumbnail only, right? That's what I get with minimal.


I wonder if users would accept it if I simply ignored THM files altogether? Keeps things cleaner

Actually, that's not what happens now. Consider a project with a regular JPG, an MP4 with a THM, a PDF with a THM, and an MP3 with a PDF. See screenshot of project - that thumbnail for the Chrome video is not coming from the video - it's a THM.

Linking to scaled images only, the slides directory contains a slide image for each one of them.- screenshot. Minimal uses the slide image for the MP4 as a poster image, before you hit Play. It doesn't need to use it for the PDF, but the slide image is actually there (in my lightbox skins, that's the image that "expands" from the thumbnail, so I am using it). Minimal doesn't use the poster image for the MP3, but Jupiter certainly does.

But now switch to linking to originals. The only poster image that lands in slides is the one for the MP4 - see screenshot.

They should all behave the same way. Regardless of whether it's linking to scaled or linking to originals, we need to have a poster image for each AO land in slides.

(ETA: And that, of course, is where things get murky when you're attaching a JPG to a JPG. In that case, you probably want only a thumbnail coming from the linked file.)

Opening an AO for editing should show you only the AO, and never its RI. After all, you can't actually edit the RI. So, if you enter edit mode for a PDF, it should probably display just the generic PDF icon. Only in the Explore view should you be seeing the RI, as a thumbnail.

(And to mix subjects, when you go to a folder that has internally linked objects, you shouldn't be able to enter edit mode for those at all, since the core is not going to generate different versions of those images.)

I think that's working properly, but I'll have to do some tinkering. It's a tough thing to test - I need to reinstall jAlbum 37 to create projects for testing. It does appear to be ignoring newly-added THM files, happily.


For a PDF, that's true. But for an MP3, that leaves me with no image to use as a poster on the slide page - no scaled image, no original image. For an MP4, that would also leave me with no poster image to show before the visitor hits "play." And the lack of a poster image for the MP3 produces the classic "broken image" icon on the slide page. The user is then boxed in. If he wants to show a poster image for an MP3 or MP4, he must include scaled images for the whole project.


I suppose that for PDF's or MP3's, that's fine, as long as the user can remember that the image editing options at the top apply to the RI, but the right-panel things like the skin-specific custom UI items apply to the AO.

But attach an RI to an MP4, then enter edit mode. You're seeing the JPG RI. But the slide controls at the bottom apply to the MP4, even though you can't see what they're doing! And if I touch the video slider at all, I end up with a "red X" thumbnail. A bit of a muddle.

The situation with an JPG AO and a JPG RI is even more perplexing. Rather than try to describe it, I'll just let you try it. Try using something obvious, like "invert" on the image edit. Pay attention to what you're seeing in the Explore view, and what images are landing in the album output. Now tag the AO as "use original," and see what happens. Fun for the whole family!

b20 now available, adding a context menu when clicking an attachment and also fixing a thumbnail rendering performance issue introduced with attachments.