How to do this…is there any old discussion regarding this or any documentation available for reading?
Regarding getting workable random numbers within a range this is still useful … https://groups.google.com/g/tiddlywiki/c/N263pebgCYI/m/W0qL_wwsAwAJ
Hi @Mohammad, working on a lightbox is actually pretty high on my list of things that I need for my own TW apps. I am hoping to find the time for it later this summer and will keep you posted once I do work on it.
A lightbox is actually a lot more work with a lot of details to consider than is apparent at first, which is why I have decided against a custom JS or wikitext approach. However, the challenge then is to find a library that actually meets all of my criteria and would integrate well with TW. The one you linked is one of many that I have bookmarked for review when I get the opportunity.
1 Like
The approach both TiddlyWiki on Fission and my own WebDAV work takes is to have an action that makes an HTTP request to the server to get a list of images. This is saved as tiddler(s) and then creating a gallery is just wikitext based on those tiddler(s). If using PHP, you would need a script that when queried via HTTP returns a list of image filepaths in the folder.
1 Like
Ciao @saqimtiaz
I am very interested in what you might go with! I agree there are good libraries. But it needs a review to know what would be optimal for us.
ONE interest I have, that often gets overlooked, is meta-data already embedded in image files like JPG & TIFF. For my kind of projects: being able to dynamically fetch that meta-data, rather than have to laboriously re-create it in TW would make a big difference. Certainly the high-end commercial lightboxes like Adobe’s Lightroom make heavy use of meta-data. In effect the image is it’s own documentation.
Just a comment!
But I thought one that might have your interest too?
Best wishes
TT
Yes metadata such as embedded exif is very valuable, especially with photography and getting camera and exposure details. If only this were able to be transferred into tiddler fields it would achieve the majority of desirable functionality. You can write back to the tiddler if not the image file.
Perhaps I do not understand what a light Box is (I thought I did)
I have to be honest I do not understand what people see in this concept of a lightbox, the real world ones are just displaying a transparency with a backing light, we have screens/monitors for this.
- To me, rather than exception handling through some “lightbox” library what we need to do is;
- work on the ways we can arrange the display of images in tiddlers within tiddlywiki,
- This can in fact support the display of any tiddler content eg previews, pin board, Muuri, multi-col…
- and empower the import of metadata from image files into the tiddler
- work on the ways we can arrange the display of images in tiddlers within tiddlywiki,
For example we can already do these things;
- Arrange and format content within a tiddler almost any way we want
- This includes content from other tiddlers,
basically a tiddler that presents a view of multiple tiddlers eg a lightbox
- This includes content from other tiddlers,
- Totally Modify what a tiddler looks like when it appears in the story
- Swap out the story mechanism for another with layouts.
- use windows, popups, modal, slideshow to allow full screen image viewing.
To me all the features I can imagine in a lightbox are either already available in tiddlywiki, or could be transferred into tiddlywiki such that not only can lightbox features be available but more fundamental features made available to tiddlywiki users. Eg; tools for the responsive tiling of images.
I am not saying importing a lightbox library is not valuable, but perhaps generalising and building in to tiddlywiki (Via a plugin) the functionality of lightboxes is more reusable and flexible.
Or is there some magical feature of lightbox solution I just do not understand?
1 Like
Yes, I have a list of libraries to review and somewhere I also have a list of requirements that I wrote down a while back. Now I just need to find a solid chunk of time. I actually found a library last year that was almost a good fit and offered to fund the developer to add the few missing features. Sadly I could not get him to bite even though he was looking for sponsorship.
In terms of needs and workflow I am at the other extreme. The only time I find EXIF data at all useful is with RAW format images in Lightroom or other RAW image processing software. The RAW photos with the useful metadata I never want modified and never come anywhere near a TiddlyWiki. For the images that do have a place in TW for my workflow, extracting or saving metadata in the image would add no value.
The challenge for myself with writing plugins is really about the time and effort required for ongoing maintenance and support rather than in initially creating them. The only sustainable model I have found is to only publish plugins that I use myself and would therefore naturally keep updated, and otherwise just feed the learnings from my own private plugins into the TW core where appropriate.
@saqimtiaz et al have you considered the value that embedded image data can provide?
- extracting the geolocation info from photos, where was it taken
- also allows mapping, link to map or trails.
- combined with date and time, if you have separate info, like notes or a second camera time/date allows you to plot them all together on a path by using the time to synchronise.
- Actual time of day - morning afternoon and evening - for “the light”
- Actual date - can sort in order when documenting an event or journey.
- The camera used, if more than one in use, to assist in sorting the source of the photos and the photographer.
All of the above and more help manage the metadata of photos at least and can be used in smart ways to quickly group, tag and arrange photos, something which tiddlywiki is already good at.
Of course basic handling needs to come first, but I think keeping these possibilities available are important.
- Perhaps metadata is present inside the binary tiddler, and could be extracted later?
@TW_Tones I was asked about my personal interest by TT. EXIF data has no added value for me in TW, which in no way precludes that it may be of interest to others.
I do strongly suggest that if there is interest in discussing this topic further that a separate thread be started, both to allow it proper attention and to not further derail the original topic of this thread from which the issue of image metadata is quite distinct.
Not that it helps much, but a few comments.
Right. To be able to extract meta-data from images would give the edge towards full-pro lightboxes. This is what the “big photo apps” do.
Use case: 4,000 paintings of Bonfire Night in the UK.
FYI, in that use case there is NO way I’d ever need or want TW to permanently import the meta-data. Merely dynamically read it for a lightbox.
Here all that is needed is TW selects a number of images to present and temporarily retrieves meta-data from, say, 50 images, for a lightbox.
The point is the images already hold the data so why add it again (for that use case)?
In this case I already conceive the “image” as a kind of “external tiddler” 
Just a comment
TT
Ciao @saqimtiaz
I disagree. It is fine with the OP.
“Lightboxes” can include meta-data reading and I wanted to flag it in case folk like you were interested.
Why? Because I’m not a developer so defer to folk like you—though on images for “Lightboxes” I do know the issues.
So. I’m really happy you are interested in the general “Lightbox” issue since you are so good. And understand you are not interested in meta-data.
But occasionally I am on the final ball :-).
Best wishes
TT
From an end-user point of view it might seem that way, but from an implementation point of view reading and display the metadata are two completely different things.
A lightbox can make use of and display any data that is available. The issue of having access to image EXIF data in TW is completely distinct from implementing a lightbox, and should also be implemented separately as a re-usable component. It also requires further in depth discussion as to what the usage patterns and needs might be, which would be facilitated by a separate dedicated thread. This would also make it more likely to attract the interest of someone that may implement it.
The suggestion for a separate thread is meant just as much to further your goals and needs, as to not clutter this one with details that are not directly pertinent to the implementation of a lightbox. I will leave it for you to decide whether you find value in that.
Right. Understood.
TBH, it is a conundrum. I highly appreciate what you do. And I also see the conundrum of open source, free. A legacy of maintenance no one pays you for.
Though this post should maybe split to the Café?
TT, x
I will shut-up on this thread now as I certainly don’t want to spoil it.
TT
Sorry for having brought up this metadata thing 
Thanks for the quick exif-experiment @saqimtiaz !
I thought the description (which is in fact an IPTC-feature) could help building a lean and dynamic gallery which from a folder.
Another idea could be a combination of geoloc-data with the leaflet plugin.
@Mohammad here is a very very quick proof of concept of integrating Spotlight into TW: Spotlight — proof of concept
I only had under a half hour to kill between meetings so please do not expect too much!
I do not believe that Spotlight lets you do inline sliders, which would be nice to have for my intended use case.
We may also need to disambiguate the functionality of a lightbox versus that of a creating a masonry or tiled view of images, to facilitate discussion. The description of Spotlight as a “lightbox gallery” is potentially misleading.
5 Likes
Slightly off-topic,
They your photos Saq? They are good!
All photos used for the demo are from https://unsplash.com/
Somehow using my own work feels inappropriate.
1 Like
I kinda understand that. But it is always interesting to me to see a “corpus” of work.
I do work with “would-be” photographers. It always amazes me how good they are without knowing it!
A comment
TT