Posts:
7,956
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum on Java 18
Posted:
22 Sep 22, 22:28
in response to: RobM
|
|
|
|
Offered up, FWIW....
I just got through Groovying (now, there's a new gerund) the Jupiter code. This skin is the beast of the bunch, with all kinds of ugly stuff. From start to finish, it took 45 minutes. Subsequent skins will take less time, partly because some of the ugliest chunks of Jupiter code are shared with other skins, and can be copied and pasted into them.
Amusing side note: I kept running into a void variable problem, and discovered that it's a harmless bug that's been in the skin since version 1. BeanShell just ignored it, but Groovy refused to do so.
|
|
|
Posts:
3,948
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum on Java 18
Posted:
22 Sep 22, 23:03
in response to: JeffTucker
|
|
|
Offered up, FWIW....
I just got through Groovying (now, there's a new gerund) the Jupiter code. This skin is the beast of the bunch, with all kinds of ugly stuff. From start to finish, it took 45 minutes. Subsequent skins will take less time, partly because some of the ugliest chunks of Jupiter code are shared with other skins, and can be copied and pasted into them.
I've nearly got into the Groove with Journal skin (taken it slower but) very nearly there. I hope I'm down to my last issue An unexpected error occurred. Please see detailed description below:
bsh.InterpreterError: Not a wrapper type: 222.5
at bsh.Primitive.<init>(Primitive.java:158)
at se.datadosen.jalbum.AlbumBean.primitiveWrapper(AlbumBean.java:6116)
at se.datadosen.jalbum.AlbumBean.pushVars(AlbumBean.java:6182)
at se.datadosen.jalbum.ASTEvaluator.enterScope(ASTEvaluator.java:56)
at se.datadosen.jalbum.AlbumBean.makeIndexPages(AlbumBean.java:3766)
at se.datadosen.jalbum.AlbumBean.makeAlbumForFolder(AlbumBean.java:1849)
at se.datadosen.jalbum.AlbumBean.makeAlbumForFolder(AlbumBean.java:1995)
at se.datadosen.jalbum.AlbumBean.makeAlbum(AlbumBean.java:3266)
at se.datadosen.jalbum.AlbumBean.smartMakeAlbum(AlbumBean.java:3158)
at se.datadosen.jalbum.JAlbumFrame$7.run(JAlbumFrame.java:1170)
Now I know the problem is within a method in init.groovy starting at line 448 but the error message doesn't mean anything to me (which line(s) to look at. And why is it reporting a bsh.InterpreterError |
|
|
Posts:
7,956
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum on Java 18
Posted:
22 Sep 22, 23:38
in response to: RobM
|
|
|
Haven't seen that one. Your code must be extra special.  |
|
|
Posts:
3,948
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 00:00
in response to: JeffTucker
|
|
|
Haven't seen that one. Your code must be extra special.
I've tracked it down. In init.bsh I had tocWidth = vars.get("thumbWidth");
...
tocWidth = ai.getImage().getWidth()/2;
So In Groovy I tried the same code and it didn't like it at all. So I tried using def tocWidth and it didn't like that either. I'm now using int tocWidth = vars.get("thumbWidth");
and it works.
I just have one more thing to fix, now that it is actually making the album without an actual hard error. |
|
|
Posts:
7,956
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 00:17
in response to: RobM
|
|
|
|
Yes, I suppose without the cast to int, Groovy gets confused. It's very loose about data types, pretty much responding to whatever it's fed. But a get() on vars returns a String.
ETA: And yeah, once you get through an album build, the remaining bits and pieces get a lot easier.
|
|
|
Posts:
3,948
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 00:31
in response to: JeffTucker
|
|
|
Last problem with Groovy, theme images.
This problem would be best solved by jAlbum core taking care of it.
The problem, if webP is selected as the output format under Images>Advance then the jAlbum built in method of making theme images should produce webP theme images, not JPG as it does.
My code that worked in .bsh but won't in Groovy //Turn on theme image support, using the selected output format of jpg or webp
//Set the them image name
themeImageName = "folderimage.jpg";
if(engine.getOutputFormat().toString().equals("WebP")) {
themeImageName = "folderimage.webp";
}
//Setup the custom theme image method
ThemeImageProcessor custom = new ThemeImageProcessor() {
public getThemePath(AlbumObject folder) {
return themeImageName; //Line 71
}
};
//Invoke the theme image processor
engine.setThemeImageProcessor(custom);
Error Stack trace for jAlbum 29b14 using skin Journal Groovy 16:
se.datadosen.util.ScriptException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/Users/robert/Library/JAlbum/skins/Journal Groovy/init.groovy: 70: The return type of java.lang.Object getThemePath(se.datadosen.jalbum.AlbumObject) in init$1 is incompatible with java.lang.String in se.datadosen.jalbum.ThemeImageProcessor
. At [70:3] in init.groovy at line number 70 at column number 3
|
|
|
Posts:
7,956
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 00:43
in response to: RobM
|
|
|
I don't think you can "persuade" the core to produce a WEBP theme image. You might be able to get it to give it that file extension, but I'm betting that the internal image format is still JPG.
In any event, without that wrinkle, this is what's working for me (with some extra complications because of options about using the same theme image for folders, or unique ones for each): // Theme images
custom = new ThemeImageProcessor() {
public String getThemePath(AlbumObject folder) {
return "ja-theme.jpg";
}
};
customTO = new ThemeImageProcessor() {
public String getThemePath(AlbumObject folder) {
return "ja-theme.jpg";
}
public void processThemeImage(AlbumObject folder, File outputDir) throws IOException {
if(folder == rootFolder) {
super.processThemeImage(folder, outputDir);
}
}
};
if(!themeNone && themeFolders) {
engine.setThemeImageProcessor(custom);
}
else if(!themeNone) {
engine.setThemeImageProcessor(customTO);
}
themeRoot = JAlbumUtilities.getThemeObject(rootFolder) != null;
|
|
|
Posts:
7,956
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 01:01
in response to: JeffTucker
|
|
|
|
BTW, your existing Journal skin refuses to produce a WEBP theme image. It doesn't just produce a mis-labeled JPG - the album build actually errors out.
|
|
|
Posts:
3,948
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 08:58
in response to: JeffTucker
|
|
|
BTW, your existing Journal skin refuses to produce a WEBP theme image. It doesn't just produce a mis-labeled JPG - the album build actually errors out.
Thanks for your code. I’ll have to try Journal on older versions of jAlbum as I’m sure I checked the output format with exiftool. But if webP is selected as the output format the core should produce webP theme images by default. |
|
|
Posts:
3,648
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 11:20
in response to: JeffTucker
|
|
|
The error that could potentially happen is that the wrong method is being called, but I can't foresee how that would happen in reality.
I'd vote to stick it in the final jAlbum 29 release and see what happens. Easy enough to back it out quickly if there are smoke and flames.
So, in the pompous jargon of the OpenJDK folks, are we now in Rampdown Phase II on jAlbum 29? Just curious, since I'm in the midst of converting my skins to Groovy.
Yes, we've very close to release now. The only (me knowingly) outstanding issue is missing RAW support for M1 Macs. I can live with that initially, but I'll make one more attempt on addressing it (involves fighting native code integration with Java JNA) |
|
|
Posts:
3,648
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 11:23
in response to: RobM
|
|
|
Unless there is a way of compiling a Groovy UI for an external tool then the complete lack of BeanShell means a problem for some of my external tools. Loading, for example reading mp3 tags, could take a very long time to load.
Have you tested? I won't dump BeanShell as of v29, but I want to encourage people to move away from it as it's stuck in 2005.
Maybe the question that needs to be asked is what external tools do users still want.
Good question. I have no clue. Should do some cleaning up there. The "Server mode" tools should be removed by now as the Multi Maker + project monitoring should do that job. |
|
|
Posts:
3,648
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 11:29
in response to: RobM
|
|
|
Maybe the question that needs to be asked is what external tools do users still want.
Very good question. 
What I use constantly is:
textsToComments.bsh
A button, a File chooser, two sets of three radio buttons and the OK/Cancel button. That might be a bit slow in loading, but probably acceptable - especially if there is no alternative (other than letting users hard code their choice of settings). On my watch list for Groovyfication.
I wouldn't worry a bit when it comes to performance on such modestly sized UIs. Compare with a skin like Tiger or SimpleViewer for instance. Such skins needs to be compiled.
I've also noticed that "Groovyfying" the code too much slows down parsing significantly, so even if code like System.out.println("foo"); can be replaced by print "foo" (no ending semicolon), such "groovy-style" coding slows down parsing. Stick to plain Java syntax for performance and ease of porting to Java if needed later down the road. |
|
|
Posts:
3,648
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 11:44
in response to: RobM
|
|
|
Offered up, FWIW....
I just got through Groovying (now, there's a new gerund) the Jupiter code. This skin is the beast of the bunch, with all kinds of ugly stuff. From start to finish, it took 45 minutes. Subsequent skins will take less time, partly because some of the ugliest chunks of Jupiter code are shared with other skins, and can be copied and pasted into them.
I've nearly got into the Groove with Journal skin (taken it slower but) very nearly there. I hope I'm down to my last issue An unexpected error occurred. Please see detailed description below:
bsh.InterpreterError: Not a wrapper type: 222.5
at bsh.Primitive.<init>(Primitive.java:158)
at se.datadosen.jalbum.AlbumBean.primitiveWrapper(AlbumBean.java:6116)
at se.datadosen.jalbum.AlbumBean.pushVars(AlbumBean.java:6182)
at se.datadosen.jalbum.ASTEvaluator.enterScope(ASTEvaluator.java:56)
at se.datadosen.jalbum.AlbumBean.makeIndexPages(AlbumBean.java:3766)
at se.datadosen.jalbum.AlbumBean.makeAlbumForFolder(AlbumBean.java:1849)
at se.datadosen.jalbum.AlbumBean.makeAlbumForFolder(AlbumBean.java:1995)
at se.datadosen.jalbum.AlbumBean.makeAlbum(AlbumBean.java:3266)
at se.datadosen.jalbum.AlbumBean.smartMakeAlbum(AlbumBean.java:3158)
at se.datadosen.jalbum.JAlbumFrame$7.run(JAlbumFrame.java:1170)
Now I know the problem is within a method in init.groovy starting at line 448 but the error message doesn't mean anything to me (which line(s) to look at. And why is it reporting a bsh.InterpreterError
Please ensure that you've updated to the latest beta core jar file at https://jalbum.net/download/beta/jalbum-core.jar, then re-post your stack trace. At this moment I can't debug properly as my version differs from yours. You should only receive these errors if the BeanShell script engine is active.
Edited by: JeffTucker on 23 Sep 2022, 07:46 to fix link (the forum software grabs the trailing comma). |
|
|
Posts:
3,648
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 11:51
in response to: RobM
|
|
|
se.datadosen.util.ScriptException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/Users/robert/Library/JAlbum/skins/Journal Groovy/init.groovy: 70: The return type of java.lang.Object getThemePath(se.datadosen.jalbum.AlbumObject) in init$1 is incompatible with java.lang.String in se.datadosen.jalbum.ThemeImageProcessor
. At 70:3 in init.groovy at line number 70 at column number 3[/code]
Well, your method declaration is missing the "String" return type, see: public getThemePath(AlbumObject folder) {
return themeImageName; //Line 71
}
, just add String after public.
|
|
|
Posts:
1,156
Registered:
14-Dec-2007
|
|
|
|
Re: jAlbum on Java 18
Posted:
23 Sep 22, 12:30
in response to: davidekholm
|
|
|
Yes, we've very close to release now. The only (me knowingly) outstanding issue is missing RAW support for M1 Macs. I can live with that initially, but I'll make one more attempt on addressing it (involves fighting native code integration with Java JNA)
Don’t spent any time to RAW support for jAlbum if jAlbum can’t read the edits made in Lightroom, because nobody will use it!
What about the final pop-up window with the Multi maker? |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
