Another big difference between X3 and Koken, is X3's superior CACHE
mechanism. Once a page in X3 is created for the first time, it loads extremely fast, something I am sure you have noticed and appreciate. The cache mechanism depends on the CHANGES to the folder ... If the folder changes (settings or new images), the page will get re-created. This works fine for the page's own folder, as it can just check folder-date and/or changes to settings/page. However, if the page depends on unknown data/images spread across multiple (or possibly 100's) of folders, the process could become incredibly slow and impossible to implement. This cache mechanism is also therefore affected if you want to load and validate data/images from other folders.
metallissimus wrote:Maybe X4 will be able to do that? I can only guess that it might be possible to implement some kind of watching mechanism that detects changes and can rewrite the symlinks correspondingly.
In terms of X4 (or next-gen X3), I could write a lot. There is definitely room for huge improvements in how X3 stores images and data on a per-folder basis. For example, the following is feasible (although not without some complications):
- Show latest images (from multiple dirs), as X3 could do this by scanning various folders data files.
- Load images into a gallery from multiple dirs, also by scanning various folders data.
However, the above is purely "dynamic" features that don't rely on fixed paths. If you refer multiple images by file path into pageA from pageB/C/D, you can't expect pageA to track or "watch" for changes to the references. That would be either A ) On click "save" in pageA, check all image references, and if they don't exist, just remove them ... But even here, if you change paths or images in pageB/C/D, you can't expect pageA to automatically update itself. B ) On click "save" in pageB/C/D, loop ALL other pages, check if they have special references to images in itself, and then refresh pageA. In conclusion, none of these options are feasible.
The only thing I can thing of, would be some kinda "tags" mechanism
, which could allow you to load images by tags, into any page/gallery, including a slideshow-intro. Tags, without a database, surely is not an easy concept either, but it might be achievable somehow.
Another option could be to "mark image for slideshow" from any gallery, and that would create a list of images (from multiple dirs) to use for the slideshow. However, this logic means there would only be ONE set of "marked images" that could be used in any gallery (or slideshow-intro), and we would have to create a "select" interface just for this "set".
All this just to avoid copying a few select images directly into your slideshow-intro folder, which after all isn't too complicated. Not saying there aren't good options here, but just concluding the facts. Food for thought!