I am getting ready to post a new version of Mirage; just doing some final checks.

I am using the "Image bounds / Folders" setting to force a static folder thumbnail size.
hints.jap contains

processFolderThumbs=true
folderThumbSize=82x54

skin.properties contains

disabledControls=processFolderThumbs,folderThumbSize

When I create a project, or switch from Tiger to Mirage, folderThumbSize is correctly set to 82x54, but I can change this setting; if I hover over the selector, a message "Disabled by current skin" is shown, but I am able to change the thumb size.

Do I need to set something else, or is this a jAlbum buglet?

No; thumbnailLayoutPanel is in a different area (number of thumbnail columns and rows). This is not relevant.

I can confirm that unwanted behavior. David usually checks posts in this forum section, but if you don't hear from him, you might want to post a regular bug report.

That said, I'm always a bit leery of skins that force things like image dimensions on users. Users tend to get very shirty about things like that.

Edit the skin.properties file for Atom, and add folderThumbSize to the list of disabled controls. Now do whatever you like, at whatever leisurely pace you desire - relaunch jAlbum and choose Atom, for example. The folder thumbnail bounds can still be accessed by the user.

Ok, I can reproduce it with Atom.
Looking at Atom.java:188

new StateMonitor() {
    public void onChange() {
        window.ui2Engine();
        engine.setProcessFolderThumbs(folderSection.isSelected());
        window.engine2UI();
    }
}.add(folderSection).done();

That's what's causing it. When folderSection is being ticked during a engine2UI call (when skin loads), then your onChange is triggered which sets processFolderThumbs. jAlbum in turn has another rule that enables the folderThumbSize UI control whenever processFolderThumbs is ticked.

Do you really wish to have a situation where processFolderThumbs is ticked without folderThumbSize is being enabled?

Well, one naturally expects the disabledControls skin property to be respected so I've fixed this now by checking whether anyone "vetoes" a setEnabled call. This new veto mechanism for components is now respected by ComponentUtilities and StateMonitor.

(Tech details: You can add a veto to a component's setEnabled call by calling ComponentUtilities.addEnabledVeto(comp, veto) where "comp" is the component to add a veto to and "veto" is any object that represents the veto. Later on, you can remove the veto by calling ComponentUtilities.removeEnabledVeto(comp, veto). When a skin specifies components to be disabled, then I add a veto to each such component)

All in v34.2.3 (core update)