|
Replies:
16
-
Pages:
2
[
1
2
| Next
]
-
Last Post:
17 Dec 25, 17:27
Last Post By: davidekholm
|
|
|
Posts:
3,824
Registered:
18-Oct-2002
|
|
|
|
v38.2.3 for testing
Posted:
5 Dec 25, 16:50
|
|
|
I've added an experimental "targetCloseupPath" variable that will point you to the slide page of the target of the current album object, so if the viewer is navigating inside a view and wishes to see the corresponding image in its original context, then he can follow a link made with this variable.
This currently only works if "internal linking" is on and if slide pages are being generated.
To test, delete asm from jAlbum's lib folder and unzip https://jalbum.net/download/libs.zip to it
also replace jalbum-core.jar with https://jalbum.net/download/beta/jalbum-core.jar
v38.2.3 also fixes some bugs with the AlbumObject API, that caused the heart icon to go away when reloading a view.
The more exciting (for me) part of this update is the use of the cglib library for code generation. I've rewritten how internal links are implemented using it, so look out for any new bugs. The purpose of introducing cglib is to avoid the heavy code duplication that the current internal linking implementation suffers from. In short: This new implementation may contain some early bugs, but it's for the better (to avoid future bugs when extending the AlbumObject API)
Cheers
/David |
|
|
Posts:
3,824
Registered:
18-Oct-2002
|
|
|
|
Re: v38.2.3 for testing
Posted:
5 Dec 25, 17:27
in response to: davidekholm
|
|
|
|
hmm, this is getting too technical. You apparently also need to add another command line switch to make it work:
--add-opens java.base/java.lang=ALL-UNNAMED
|
|
|
Posts:
8,052
Registered:
31-Jan-2006
|
|
|
|
Re: v38.2.3 for testing
Posted:
5 Dec 25, 17:33
in response to: davidekholm
|
|
|
I've added an experimental "targetCloseupPath" variable that will point you to the slide page of the target of the current album object, so if the viewer is navigating inside a view and wishes to see the corresponding image in its original context, then he can follow a link made with this variable.
This currently only works if "internal linking" is on and if slide pages are being generated.
I'm puzzled about the impetus behind this. There are very few active skins that produce separate slide pages, and most of those aren't often used.
What would be more useful would be a path to a slide image from a folder. Please see my email titled "Folder slides?" It's related to that.
But in short, imagine FolderOne, containing dog.jpg, cat.jpg, and bird.jpg, with dog.jpg as the image for the folder. Processing FolderOne, a skin can get its folder thumbnail. But there's no reliable way, especially with internal linking and views, to get the path to FolderOne/slides/dog.jpg (scaled to the image bounds, not the folder thumbnail bounds). Without internal linking, you can cobble together the path, but with internal linking, it's going to be wrong every time. |
|
|
Posts:
3,824
Registered:
18-Oct-2002
|
|
|
|
Re: v38.2.3 for testing
Posted:
6 Dec 25, 13:13
in response to: davidekholm
|
|
|
|
I switched from the super small cglib to the modern and maintained bytebuddy lib. Update jalbum-core.jar and libs.zip
bytebuddy is unfortunately larger (now 4MB after compressing from 9MB), but doesn't need any --add-opens tricks.
|
|
|
Posts:
3,824
Registered:
18-Oct-2002
|
|
|
|
Re: v38.2.3 for testing
Posted:
6 Dec 25, 13:14
in response to: JeffTucker
|
|
|
|
Jeff, Can't you just use imagePath? If the skin isn't using folder thumbnails, then it points to the slide image that represents the folder, and it naturally respects internal links.
|
|
|
Posts:
8,052
Registered:
31-Jan-2006
|
|
|
|
Re: v38.2.3 for testing
Posted:
6 Dec 25, 14:55
in response to: davidekholm
|
|
|
Jeff, Can't you just use imagePath? If the skin isn't using folder thumbnails, then it points to the slide image that represents the folder, and it naturally respects internal links.
I should probably dump this on RobM, since it's one of his strange skins that's involved. But in short, he needs both. If the first object on the page is a folder, he wants its representing slide image. But if it's not the first object on the page, he needs the folder thumbnail image.
If folder thumbnails are supported, imagePath and thumbPath are identical. Yet another "slippery" variable whose meaning changes depending upon context.  |
|
|
Posts:
3,947
Registered:
4-Aug-2006
|
|
|
|
Re: v38.2.3 for testing
Posted:
6 Dec 25, 15:46
in response to: JeffTucker
|
|
|
Jeff, Can't you just use imagePath? If the skin isn't using folder thumbnails, then it points to the slide image that represents the folder, and it naturally respects internal links.
I should probably dump this on RobM, since it's one of his strange skins that's involved. But in short, he needs both. If the first object on the page is a folder, he wants its representing slide image. But if it's not the first object on the page, he needs the folder thumbnail image.
As you know, we’ve not found an elegant way to do this, the existing code works perfectly for ordinary objects. It breaks if internal links/views are included, fixing it for one case breaks another. Existing code, relevant line: <img src="<%=label.replaceAll(" ","%20")%>/
out.print(engine.getCloseupDirectory() + "/");%>
<%=currentObject.getRepresentingImageFile().getName().replaceAll
(" ","%20");%>"
If folder thumbnails are supported, imagePath and thumbPath are identical. Yet another "slippery" variable whose meaning changes depending upon context. |
|
|
Posts:
3,947
Registered:
4-Aug-2006
|
|
|
|
Re: v38.2.3 for testing
Posted:
6 Dec 25, 17:54
in response to: davidekholm
|
|
|
Jeff, Can't you just use imagePath? If the skin isn't using folder thumbnails, then it points to the slide image that represents the folder, and it naturally respects internal links.
The skin Jeff And I have been trying to make work with view and internal links is Missive. I’ll turn off folder thumbnails and go with that as the easiest solution. |
|
|
Posts:
3,824
Registered:
18-Oct-2002
|
|
|
|
Re: v38.2.3 for testing
Posted:
7 Dec 25, 20:50
in response to: RobM
|
|
|
|
I don't know how much this helps, but the current beta now has a "targetPath" variable that exists for internal links only. It then points to the target of the internal link.
|
|
|
Posts:
3,947
Registered:
4-Aug-2006
|
|
|
|
Re: v38.2.3 for testing
Posted:
7 Dec 25, 21:45
in response to: davidekholm
|
|
|
I don't know how much this helps, but the current beta now has a "targetPath" variable that exists for internal links only. It then points to the target of the internal link.
I'll have a look at the beta, but I'm tied up on other stuff (outside of jAlbum, alas) at the moment, probably a week or so. |
|
|
Posts:
3,947
Registered:
4-Aug-2006
|
|
|
|
Re: v38.2.3 for testing
Posted:
8 Dec 25, 20:50
in response to: davidekholm
|
|
|
hmm, this is getting too technical. You apparently also need to add another command line switch to make it work:
--add-opens java.base/java.lang=ALL-UNNAMED
Sorry, I've forgotten where to add this switch on a Mac, I (think) know it's the ini file for Windows |
|
|
Posts:
8,052
Registered:
31-Jan-2006
|
|
|
|
Re: v38.2.3 for testing
Posted:
8 Dec 25, 20:56
in response to: RobM
|
|
|
hmm, this is getting too technical. You apparently also need to add another command line switch to make it work:
--add-opens java.base/java.lang=ALL-UNNAMED
Sorry, I've forgotten where to add this switch on a Mac, I (think) know it's the ini file for Windows
I don't remember, either, but with the latest beta core, you don't need to. |
|
|
Posts:
3,947
Registered:
4-Aug-2006
|
|
|
|
Re: v38.2.3 for testing
Posted:
8 Dec 25, 22:42
in response to: JeffTucker
|
|
|
hmm, this is getting too technical. You apparently also need to add another command line switch to make it work:
--add-opens java.base/java.lang=ALL-UNNAMED
Sorry, I've forgotten where to add this switch on a Mac, I (think) know it's the ini file for Windows
I don't remember, either, but with the latest beta core, you don't need to.
Quick test.
JAlbum 38.2.5, Java 23.
The resulting code is pointing to an original image in the album, which might not exist. If it can target the correct album image it looks good - but I need to also have it work with no slide pages. |
|
|
Posts:
3,824
Registered:
18-Oct-2002
|
|
|
|
Re: v38.2.3 for testing
Posted:
10 Dec 25, 12:00
in response to: RobM
|
|
|
Quick test.
JAlbum 38.2.5, Java 23.
The resulting code is pointing to an original image in the album, which might not exist. If it can target the correct album image it looks good - but I need to also have it work with no slide pages.
targetPath should work with or without slides being produced, but it can surely (and mostly) create links to non existent files. It will actually only generate a working link if you include the original. The point of this variable is to allow the skin developer to more easily produce an index page link for instance. Perhaps we should only generate a targetIndexPage variable instead?
|
|
|
Posts:
3,947
Registered:
4-Aug-2006
|
|
|
|
Re: v38.2.3 for testing
Posted:
10 Dec 25, 13:09
in response to: davidekholm
|
|
|
Quick test.
JAlbum 38.2.5, Java 23.
The resulting code is pointing to an original image in the album, which might not exist. If it can target the correct album image it looks good - but I need to also have it work with no slide pages.
targetPath should work with or without slides being produced, but it can surely (and mostly) create links to non existent files. It will actually only generate a working link if you include the original. The point of this variable is to allow the skin developer to more easily produce an index page link for instance. Perhaps we should only generate a targetIndexPage variable instead?
It’s easy to check if an original object exists or not. I could manipulate the result to make it point to the slide image, which would have any filters applied.
For me, I can’t think of a use to target the index page, so the targetPath gets my vote. |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
