Posts:
3,939
Registered:
18-Oct-2002
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 12:40
in response to: davidekholm
|
|
|
|
With b13, internal links also works with other structures than mirror, but there is still a caveat: You first need to generate that gallery using a mirrored structure. That's what produces the images in their "right" locations. After that you can generate several other structures, like calendar or flatten. They will now refer to the original mirrored structure.
I realise that we may have opened a "can of worms" here so we'll likely only use internal linking in a gallery if the skin is flagged to supporting it.
|
|
|
Posts:
3,939
Registered:
18-Oct-2002
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 13:53
in response to: davidekholm
|
|
|
Now b14 is available as a beta jar file
Changes:
There are two new text strings as well (goes into texts/texts.properties):
ui.useInternalLinking=Use internal linking
ui.useInternalLinkingToolTip=Reduce album size by allowing objects to be referenced across album folders
|
|
|
Posts:
8,297
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 14:08
in response to: davidekholm
|
|
|
I realise that we may have opened a "can of worms" here...
This must the royal "we." I think I can speak for the rest of the developers when I say that we were not suffering from a worm shortage. 
.... so we'll likely only use internal linking in a gallery if the skin is flagged to supporting it.
What would render a skin capable, or not capable, of supporting internal linking? |
|
|
Posts:
8,297
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 14:14
in response to: JeffTucker
|
|
|
|
BTW, I hate to think what this will do with chained directories.
|
|
|
Posts:
8,297
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 15:00
in response to: davidekholm
|
|
|
b13 is now available as a beta core file, fixing linking issues involving gifs, videos and the use of "Use original"
Better. But I can still trip it up very easily. (I've set both Minimal and Neptune to enable internal linking, just for testing.)
Create a linked image in a folder, then tag that linked image as "Use original."
A GIF works properly, but an image doesn't, and the reason is clear. In the parent folder, mydog.jpg isn't tagged as "use original," so the original doesn't get copied to the output folder. The linked copy of that image, however, is looking for that original in the output folder, and it's not there. |
|
|
Posts:
3,939
Registered:
18-Oct-2002
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 15:21
in response to: JeffTucker
|
|
|
What would render a skin capable, or not capable, of supporting internal linking?
As long as the skins don't rely on slide images, originals and thumbnails to reside in any particular folder, but instead use the originalPath, imagePath and thumbPath variables (and respective variants), then it qualifies to support internal linking.
|
|
|
Posts:
8,297
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 15:52
in response to: davidekholm
|
|
|
What would render a skin capable, or not capable, of supporting internal linking?
As long as the skins don't rely on slide images, originals and thumbnails to reside in any particular folder, but instead use the originalPath, imagePath and thumbPath variables (and respective variants), then it qualifies to support internal linking.
That's about what I suspected. I can think of only place in my skins where I'm hard-coding something, and that's to work around a very obscure jAlbum bug.
I've mentioned this one before, but it's so rare, it's not worth fixing at this point: an MP3, plus a THM, plus including only original images. The original of the THM/JPG doesn't get copied to the output, so the slide page can't find it when it's trying to put up a poster image. I do the copying of the poster image myself, but the page has to assume that the file will be in the current output folder, not in some parent folder. |
|
|
Posts:
8,297
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 15:59
in response to: JeffTucker
|
|
|
|
BTW, the current beta has trouble with any object, like a PDF, that has a THM, regardless of whether it's doing scaled images or not. If the PDF/THM are internally linked in another folder, the THM gets separated from its PDF. The SHIFT-CTRL-drag takes only the PDF.
If you manually copy the THM to the folder of linked stuff, it behaves itself.
|
|
|
Posts:
3,939
Registered:
18-Oct-2002
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 19:35
in response to: JeffTucker
|
|
|
|
Jeff, I hope I have everyone's blessing to remove the THM support altogether once I get the new mechanism in place.
|
|
|
Posts:
8,297
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
25 Sep 25, 20:19
in response to: davidekholm
|
|
|
Jeff, I hope I have everyone's blessing to remove the THM support altogether once I get the new mechanism in place.
That certainly gets my vote. I mentioned it in this thread only as something that might be worth mentioning when doing the release. But that also assumes that creating an internal link also preserves the attached files (at present, just audio clips).
Other than that, I think my skins are all "internal linking friendly." |
|
|
Posts:
3,939
Registered:
18-Oct-2002
|
|
|
|
Re: Cleaning up path variables
Posted:
26 Sep 25, 09:43
in response to: JeffTucker
|
|
|
That certainly gets my vote. I mentioned it in this thread only as something that might be worth mentioning when doing the release. But that also assumes that creating an internal link also preserves the attached files (at present, just audio clips).
Sounds reasonable
Other than that, I think my skins are all "internal linking friendly."
Great! Remember to mark them with the supportsInternalLinking=true skin property |
|
|
Posts:
8,297
Registered:
31-Jan-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
26 Sep 25, 14:31
in response to: davidekholm
|
|
|
Great! Remember to mark them with the supportsInternalLinking=true skin property
Maybe not until the dust settles. |
|
|
Posts:
3,939
Registered:
18-Oct-2002
|
|
|
|
Re: Cleaning up path variables
Posted:
27 Sep 25, 23:39
in response to: JeffTucker
|
|
|
|
|
b16 now available via the beta jar file.
Changes:
- Introduces a more generic Attachments concept*. One can now attach multiple files to any album object, currently the audio clip and a representing image. You can now easily attach a suitable image to represent a pdf or xls file for instance. This new addition does away with the clunky THM files. Just attach an image to use instead. Attachments need not have the same file name as the object they're attached to
- Refactored audio clips into the new Attachments concept
- Fixed bug where images marked with "Include original" didn't trigger the generation of the originalPath variable
New text strings (goes inside texts/texts.properties): #38
transferProtocol.commons_ftp=FTP (Apache Commons)
transferProtocol.commons_ftps=FTPS (Apache Commons implicit TLS/SSL)
transferProtocol.commons_ftpes=FTPES (Apache Commons explicit TLS/SSL)
ui.useInternalLinking=Use internal linking
ui.useInternalLinkingToolTip=Reduce album size by allowing objects to be referenced across album folders
ui.attachments=Attachments
ui.representingImage=Representing image
ui.hasAttachedImageToolTip=Image attached
Note:
Attachments are files that are bound to an album object. They are stored as multiple files under the folder .jalbum/attachments/fileName where fileName is the name of the album object. Once you run this version, "old" audio clips will be imported to this new location |
|
|
Posts:
3,952
Registered:
4-Aug-2006
|
|
|
|
Re: Cleaning up path variables
Posted:
28 Sep 25, 00:53
in response to: davidekholm
|
|
|
b16 now available via the beta jar file.
Changes:
- Introduces a more generic Attachments concept*. One can now attach multiple files to any album object, currently the audio clip and a representing image. You can now easily attach a suitable image to represent a pdf or xls file for instance. This new addition does away with the clunky THM files. Just attach an image to use instead. Attachments need not have the same file name as the object they're attached to
Is the method to get the attachments the same e.g. AlbumObjectProperties props = ao.getProperties();
if(props.get("audioClipPath") != null) {
Missive skin allows for images to have an alternative version, so the viewer can swap between the two. Would an alternative image be a good fit for an attachment? It would save having to generate unused thumbnails and slide pages for the alternative image. I think Jeff mentioned an alternative image for pano thumbnails too. |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
