This crops up from time to time, and could use a fix.

If a skin introduces a new variable, but a user tries to rebuild an existing album using the multi-maker, the build usually crashes because the variable is undefined. The user has to open each project in the app with the new skin version and save it, before it can be fed to the multi-maker.

When building an album with the multi-maker, it should check the variables against the skin's SkinModel.java contents, and apply the default setting for any missing variable. I don't have any sense of how much of a performance hit this might incur.

The tougher case is the one in which the skin, when loading an older project, applies its own logic to choose the new value for a variable. For example, "if this old Boolean was true, choose "whatever" for the new combobox." Taking care of that situation would require virtually mimicking the UI loading. I suspect that would really slow things down, so it might not be worth the effort.

(BTW, why is headless-settings.jap still present in the bundled skins? I don't provide it for any of my skins - it seems to be redundant. And what happens if it conflicts with the entries in SkinModel.java? Probably should be retired.)

If you decide to retire it, don't forget Tools > Skin developer > Prepare for online and console use.


I don't think so, and it would explain posts like this:

https://jalbum.net/forum/thread.jspa?threadID=60743

It's not clear to me if this involves the MultiMaker or the command line. Before the MultiMaker existed, I seem to recall running into it from the command line. I can do some experimenting later....

Tempting. It should certainly be removed from the Tools menu, at least.

Only three of the current skins have interpreted UI's - Classic Aligned 2, Minimal, and Zigzag.

Zigzag has a SkinModel.java file, so that one can be ignored.

CA2 doesn't have a headless-settings.jap file or a SkinModel.java, so that one can be ignored, as well.

Minimal has only headless-settings.jap, but that skin should be moved to legacy, anyway.

There are still a lot of users who stubbornly stick to obsolete skins. But if headless-settings.jap were ignored, the settings would be retrieved from the regular jalbum-settings.jap when using MultiMaker or the command line, so I don't think there's a case for retaining it in the core.

Thanks for your investigations Jeff!