|
Replies:
94
-
Pages:
7
[
1
2
3
4
5
| Next
]
-
Last Post:
30 Dec 25, 00:04
Last Post By: Soulportals
|
|
|
Posts:
3,935
Registered:
18-Oct-2002
|
|
|
|
Cleaning up path variables
Posted:
16 Sep 25, 16:47
|
|
|
|
|
I suspect that you skin developers have opinions about the values of certain skin variables like thumbPath, imagePath, iconPath, originalPath and contentPath. I plan to rewrite the *path variables (the code is a mess) and at the same time adjust things more to your liking  .
Attached is an ods spreadsheet listing how path variables are generated currently for the following 5 file types:
- folders
- Images
- PDF files and other non-image files
- Videos
- web locations
After the file names, the spreadsheet iterates over various combinations of the "Make slides", "Include images" and "Include originals" settings followed by the expected values for the following path variables:
thumbPath, imagePath, originalPath, iconPath, closeupPath, contentPath, videoPath
Let me know, by changing relevant expected values to your liking and highlight your changes in red, then attach your modified ods file. |
|
|
Posts:
8,292
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
16 Sep 25, 17:40
in response to: davidekholm
|
|
|
I plan to rewrite the path variables....
So, what's the good news? 
I'll have to mull this over, of course. A couple of quick thoughts....
Whatever is done for PDF files should also apply to MP3 files, not when they're included as audio clips, but when they're in the project as proper AO's. I support them in Jupiter, but nowhere else (too many issues). They both present the same basic problem, i.e., that there's no "image" to go with them.
Don't get me started on videos. 
Offhand, I can't think of any instances in which I've had to "work around" the existing path variables to get things to behave, with one weird exception. And that one exception has to do with THM files. A THM file attached to an MP3 file, coupled with "link to originals," fails to produce a poster image. The imagePath variable is pointing to where it should be, correctly, but the file itself is missing. Fringe case, but I do have to code around it. But I don't meddle with the path variable - I just copy the input foobar.thm to slides/foobar.jpg. Similar PDF/THM objects are treated properly.
(BTW, other skins that claim to support MP3's are all over the map, ranging from "no poster image at all," to "page hangs.") |
|
|
Posts:
3,956
Registered:
4-Aug-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
16 Sep 25, 21:39
in response to: davidekholm
|
|
|
|
Sorry, I don't have Open Office. But I don't recall having a problem with variable paths.
|
|
|
Posts:
8,292
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
16 Sep 25, 21:40
in response to: RobM
|
|
|
|
What spreadsheet app do you have?
|
|
|
Posts:
3,956
Registered:
4-Aug-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
16 Sep 25, 21:57
in response to: JeffTucker
|
|
|
|
Numbers ,it’s all I need.
I tried I-converter but it no longer supports the conversion.
|
|
|
Posts:
8,292
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
16 Sep 25, 22:07
in response to: RobM
|
|
|
|
|
Numbers should be able to open this - I saved it as an Excel file.
If you ever get in a bind:
https://libreoffice.org
It's what I use on both Windows and macOS machines. Freebies, and full-featured. |
|
|
Posts:
3,956
Registered:
4-Aug-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
16 Sep 25, 22:10
in response to: JeffTucker
|
|
|
Numbers should be able to open this - I saved it as an Excel file.
If you ever get in a bind:
https://libreoffice.org
It's what I use on both Windows and macOS machines. Freebies, and full-featured.
I used to use Open Office and Libre Office, back when working with friends that used Windows. Just haven’t had a need for either in ten years or more.
Got your file, thanks. |
|
|
Posts:
8,292
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
17 Sep 25, 17:34
in response to: davidekholm
|
|
|
I plan to rewrite the path variables ....
Just wondering what has given rise to this. I periodically clean up some messy code, even if it doesn't really change the result, or even the execution speed, but "if it ain't broke...."
I have to confess that I had to look up contentPath. I've never used it for anything. It's like title, one of those slippery variables that means different things in different contexts. I avoid things like that because I hate surprises.
Can't resist: originalPath should always point to a file - JPG, PDF, MP4, whatever - that is truly untouched, but is just copied to the root of the output. Then, videoPath should point to whatever video is being shown when a thumbnail is clicked. That will be either the untouched original MP4, in the root, or the processed MP4, in slides. Tagging a video with Use original should bypass all processing. Tagging it with Include original should result in both the untouched MP4 and the processed MP4 being in the output.
Not sure what that would mean for Settings > Images > General > Include. Maybe a setting parallel to the existing ones for images. It would also change what "Do not re-encode" means, or even make it redundant - I haven't thought about this in a while, so I'd have to mull it over. |
|
|
Posts:
1,500
Registered:
6-Sep-2005
|
|
|
|
Re: Cleaning up path variables
Posted:
19 Sep 25, 09:19
in response to: davidekholm
|
|
|
I gradually made workarounds for all the quirks. I wonder how fixing these quirks will ruin my workarounds. Anyway, the AlbumObject variables seem to work fine in most cases.
However, the JSON files contain some bizarre values. For example, add an XLS file:
{
path: "statisztika_3213_10226.jpg",
image: {
path: "../res/xls.png",
width: 320,
height: 320
},
original: {
path: "statisztika_3213_10226.xlsx",
width: 320,
height: 320
},
thumb: {
path: "../res/xls.png",
width: 135,
height: 135
},
fileSize: 33498,
name: "statisztika_3213_10226.jpg",
dates: {
added: 1711528802,
dateTaken: 1567697640
},
fileDate: "2019-09-05T17:34:00.0Z",
category: "other"
},
The path and name variables both contain invalid values.
Here's a PDF file:
{
path: "jAlbum-12-PressRelease.jpg",
image: {
path: "../res/pdf.png",
width: 320,
height: 320
},
original: {
path: "jAlbum-12-PressRelease.pdf",
width: 320,
height: 320
},
thumb: {
path: "../res/pdf.png",
width: 135,
height: 135
},
fileSize: 579914,
name: "jAlbum-12-PressRelease.jpg",
dates: {
added: 1534417719,
dateTaken: 1398355075
},
fileDate: "2014-04-24T17:57:55.190Z",
category: "other"
},
The same here. |
|
|
Posts:
1,500
Registered:
6-Sep-2005
|
|
|
|
Re: Cleaning up path variables
Posted:
20 Sep 25, 09:17
in response to: davidekholm
|
|
|
|
I tried the new beta, and it didn't convince me.
When we separate the folder mapping of the input from the output, we will spoil all the skins that assume these mappings match.
When the skin needs the thumbPath for the HTML file, for example, it gives a reference from the local file system, which is clearly bad, not only for the new "linked" objects but for all. I expected that only the new "linked objects" would fail.
I'm afraid every skin will be broken after this update. Using jAlbum 38 with any skins made before will fail, and older jAlbum versions with any skins made after 38 will fail too. I don't think the new "linked files" feature is worth risking this.
If we would like to introduce it, we first need to have a skin property that tells jAlbum if the skin is ready for the new model. For those skins that don't support it, we should retain the old model.
We should clearly separate variables that use input mapping from those that refer to the output, and can be used in the HREF links.
|
|
|
Posts:
3,935
Registered:
18-Oct-2002
|
|
|
|
Re: Cleaning up path variables
Posted:
22 Sep 25, 19:23
in response to: JeffTucker
|
|
|
I plan to rewrite the path variables ....
Just wondering what has given rise to this. I periodically clean up some messy code, even if it doesn't really change the result, or even the execution speed, but "if it ain't broke...."
v38 will allow internal image linking, from one part of the project to another. This allows you to avoid the generation of duplicate images and thumbnails. jAlbum could then, for instance, generate a calendar view or place view of the same gallery, in addition to the main view/folder structure the user has created. All without duplicating images.
I have to confess that I had to look up contentPath. I've never used it for anything. It's like title, one of those slippery variables that means different things in different contexts. I avoid things like that because I hate surprises.
This is what contentPath does today: if (isSupportedImage(file)) {
vars.put("contentPath", imagePath);
} else {
vars.put("contentPath", originalPath);
}
if (ao.getCategory()
== Category.webLocation) {
vars.put("contentPath", targetURL);
}
So, it's one of those variables that tries to be clever
It's more generic than "videoPath" for instance. If we allow for both original videos and processed videos in the future, then originalPath will point to the original video and contentPath and videoPath will point to the processed versions.
Can't resist: originalPath should always point to a file - JPG, PDF, MP4, whatever - that is truly untouched, but is just copied to the root of the output. Then, videoPath should point to whatever video is being shown when a thumbnail is clicked. That will be either the untouched original MP4, in the root, or the processed MP4, in slides. Tagging a video with Use original should bypass all processing. Tagging it with Include original should result in both the untouched MP4 and the processed MP4 being in the output.
Not sure what that would mean for Settings > Images > General > Include. Maybe a setting parallel to the existing ones for images. It would also change what "Do not re-encode" means, or even make it redundant - I haven't thought about this in a while, so I'd have to mull it over.
same here. Anyway, it's a good path forward if skins can use contentPath (or videoPath) more. It paves the way for ensuring that originalPath only points to an unprocessed video in the future. |
|
|
Posts:
8,292
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
22 Sep 25, 19:39
in response to: davidekholm
|
|
|
v38 will allow internal image linking, from one part of the project to another.
Why does this not give me a warm, fuzzy feeling?
I hope Rob will check in - he was experimenting with one of the betas, and discovered a link to a thumbnail image that was pointing to somewhere in the image directory, rather than in the output directory. Broken <img> tag in the album, of course.
I've stuck with jAlbum 38b1, because I'm in the midst of at least one complete skin rewrite, and couldn't deal with bugs coming from the core. And I'll be leaving Saturday for three weeks at the shore, and probably won't have much time for beta testing. |
|
|
Posts:
3,935
Registered:
18-Oct-2002
|
|
|
Posts:
8,292
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
22 Sep 25, 20:37
in response to: davidekholm
|
|
|
No immediate smoke and flames from b8, so I'll leave it "live" while I continue to do skin revisions. It might be a while before I have time to venture into the new functionality.
But it sounds as if you want to pretend that jAlbum is a server-side app, assembling pages from a stored database of images. What do you think this is, Piwigo?! |
|
|
Posts:
3,956
Registered:
4-Aug-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
22 Sep 25, 20:42
in response to: JeffTucker
|
|
|
v38 will allow internal image linking, from one part of the project to another.
Why does this not give me a warm, fuzzy feeling?
I hope Rob will check in - he was experimenting with one of the betas, and discovered a link to a thumbnail image that was pointing to somewhere in the image directory, rather than in the output directory. Broken <img> tag in the album, of course.
I think what I found with B6 is the same as Laza posted above. |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
