First, you should never be directly examining either the contents or the timestamp of a file like albumfiles.txt. For I/O efficiency, the core often doesn't write out such files while the user is actively modifying things - that file, for example, may not get written out until after the user has generated the album, and is closing the project. So, the timestamp on the file is useless.

Second, this is one of those cases in which modifying 10-year-old code is probably the wrong approach. Instead, take a look at a current skin and see how that skin is doing the same thing.

I believe what you're trying to do here is figure out if there are any new objects in this project, or in a particular folder. If so, there are now quicker ways of doing this. So, depending on what level you're at, and the current scope (i.e., are you within an iterator or not), just do:

newest = JAlbumUtilities.getDeepLastAdded(rootFolder); // for the whole project
 
or
 
newest = JAlbumUtilities.getDeepLastAdded(currentFolder); // if you're processing a folder
 
or
 
newest = JAlbumUtilities.getDeepLastAdded(currentObject); // if you're checking a folder while processing its parent folder
 
or
 
dateofthisobject = currentObject.getWhenAdded();

That will give you the date on which something was most recently added to the project or folder, or, in the last case, when this particular object was added to the project.

Then, a number of older skins tried to do their own date formatting because, if memory serves, the jAlbum core had no setting for it. Later, that resulted in a massive amount of confusion. A user would set a date format in the jAlbum settings, but because the skin had its own settings, dates in the album would be an unholy mix of the two formats. Simplest is to let the jAlbum core setting control what you're displaying:

displayedNewestDate = new FormattedDate(newest, engine.getDateFormatAsObject()).toString();

See https://jalbum.net/api/se/datadosen/jalbum/JAlbumUtilities.html#countCategories(se.datadosen.jalbum.AlbumObject)


I just posted the entire code that you need to do this, above. It really is just a couple of lines, and it's blazing fast.

Do not try to count things in the output. Because of multi-threading, that's a recipe for disaster - you might be building an index page while the core is in the middle of processing the images, meaning that the count of output slides would change each time you made the album, even with the same images.


I've been down that road, and it's a lot of thrashing about. A filter that's applied to the engine applies to every object you feed to it. To alter that, you'd have to create an object-specific variable that a user could attach to a given object (like with a check box in a custom UI panel in edit mode), then write your filter to look for that variable and either apply or not apply the filter. Be very sure you want to do that before heading down that road.

I had to check the code for this, but there IS a way for users to exclude individual images from certain filters. A user can add an image specific user variable under the Edit view called "excludedFilters" and set the name of the filter (or filters, comma separated) as the value. Geeky, yes!

For jAlbum's "Effects" (See settings->Effects, the user can right click any image and deselect that effect individually from the Effects menu. (Effects are technically very similar to filters. They basically also have a decent UI)

Ha, I'm familiar with that - checking large code bases to find out if something is possible. That's why I never comment (or is it that's why I should be commenting more often? :)) Excellent, thanks! I imagined that it might work like this if it was possible.


Will do, thanks.

As for the index/slide.htt I just cleaned those up. The index.htt is the one that really needed a clean-up and it's done. I say 'done' but I mean the clean-up I did is done. There probably could be additional things done. I made it HTML5 (I think) and responsive (I think!) and I did the same for slide.htt.

I was able to get rid of a lot of old functions, some loops and probably some other things too.

Thanks again so much. This goes in particular to jGromit but the rest of you too.

Looking at the code examples Rob linked to (thanks - I had seen it but it seems more useful now) there are additional things I can do but those will have to be another time.

Chris you pointed out the widget css. Good point. I probably ought to do that but for now I need a break and probably for a few days at the least. I could realistically submit the update here but I want to test things more (directories and subdirectories seems good though and that was one thing I wasn't sure about) before then. I also have something I want to do with one of the filters but this is all for another day.

I'll let you know if I have any other questions (I can see that being the case).

Cheers and thanks again.

I'm surprised at some of the things the validators (the W3 one you've linked to, and Total Validator, which I use) tolerate, but probably shouldn't.

Neither one complains about things like a self-closing break tag:

<br/>

This really should be banished.

And neither complains about the archaic charset (also self-closing):

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
 
Instead of:
 
<meta charset='UTF-8'>

It's a mixed bag when it comes to things that aren't wrong, but should be scrubbed, like the type attributes:

<style type="text/css">body {color: black;}</style>
<script type="text/javascript">var a="asdf";</script>
 
Instead of:
 
<style>body {color: black;}</style>
<script>var a="asdf";</script>