|
Replies:
12
-
Pages:
1
-
Last Post:
22 Nov 18, 10:21
Last Post By: RobM
|
|
|
Posts:
3,533
Registered:
18-Oct-2002
|
|
|
|
jAlbum 17.1 beta for testing
Posted:
16 Nov 18, 14:39
|
|
|
jAlbum 17.1 beta is out . I've added Groovy 3.0 Alpha to it, which now runs on Java 11 and has a true Java-like syntax for those of us that don't want to re-learn. With Groovy there's a potential for faster album processing than with BeanShell as Groovy scriptlets gets compiled under jAlbum 17.1. Groovy also supports modern-day Java constructs, like lambda expressions for instance. Check out this sample code that responds to a button press: b = new JButton("A button")
add b // Add it to the container
b.addActionListener { b.text="Im clicked" }
|
|
|
Posts:
1,158
Registered:
14-Dec-2007
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
21 Nov 18, 11:54
in response to: davidekholm
|
|
|
I did an attempt to convert the FancyBox skin to a groovy skin, but I got a long list of errors:
Stack trace for jAlbum 17.1b5 using skin FancyBoxGroovy 1.3.3:
se.datadosen.util.ScriptException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script19.groovy: 188: Method definition not expected here in onload.groovy at line number 188 at column number 2
at se.datadosen.util.ScriptException.of(ScriptException.java:59)
line 188 contains: private void getFileToRes(FileFilter filter, JTextField name) {
I think it will take a long time before I have solved all these errors, so I stopped.
If you really like that we switch to Groovy, you have to supply I think a conversion program for bsh modules.
But I wonder why you like to introduce Groovy:
- I don't see any benefit for the skin users, there is no significant speed improvement as I showed in my tests.
- I am not sure, that the old boys who made the current skins are willing to start new tricks. You have to attract fresh blood for making new skins with this language I think.
- You get a maintenance problem: you have to maintain 3 scripting languages: Beanshell, Groovy and Javascript.
And if you like to leave Beanshell, I think Javascript is a better alternative because a most skin developpers use that already in their skins (to get responsive skins, not as scripting language) and it will be longer supported as an unknow Groovy language.
But I wonder how manny skis do use Javascript as scripting language?
Users of the skins don't care in which language the skins are written, they only like to see modern responsive skins!
So I think you better use your time to implement enhancements for users of skins like support of srcsets and improvements for the Theme image. |
|
|
Posts:
3,533
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
21 Nov 18, 12:09
in response to: AndreWolff
|
|
|
Groovy is strict about one thing that BeanShell is relaxed about. In BeanShell you can just mix ordinary statements like i++ and method calls with declarations. In Java and Groovy you can only do this within { method blocks }, so try wrapping any ordinary statements in { method blocks }. That was the only thing I had to do to Minimal's UI.
Now, the introduction of Groovy is so far a TEST. I'd advice you to not convert any skin to it, but to play with it and comment (like you did). The reasons for trying to introduce it are:
- JavaScript is not well suited for building skin UIs or interacting with Java in general
- Oracle are phasing out / deprecating the Nashorn JavaScript engine we use in Tiger for instance (I hope we can include it stand-alone when this happens).
- BeanShell is very slow and doesn't compile and doesn't support modern day Java syntax like lambda expressions. BeanShell also sometimes gets confused about anonymous inner classes being declared within other classes. This complicates UI development.
Now it turns out that Groovy (currently) has a VERY slow textual parser, so Groovy isn't either well suited for skin UI design, but in all other regards it really delivers. |
|
|
Posts:
8,357
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
21 Nov 18, 13:16
in response to: davidekholm
|
|
|
BeanShell also sometimes gets confused about anonymous inner classes being declared within other classes. This complicates UI development.
If your UI uses anonymous inner classes, even if BeanShell doesn't get confused about them, you end up with a UI that takes something just this side of forever to load. That was the discovery that led me to bite the bullet and convert to a compiled Java UI. Without anonymous inner classes, the Matrix UI took about 10 seconds to load. Rewritten with anonymous inner classes, it jumped up to something closer to 30 seconds. That was the "holy crap!" moment. Compiled, it was down to about 2 seconds.
Once you clear that hurdle, there's no reason ever to go back. Error-checking while you're typing your code, instead of having things blow up when you try to load the skin, and once compiled, the UI loading is fast.
Haven't tinkered with Groovy yet - I'll let RobM play with it for a while so that when I finally get around to it, and get stuck, I can pester him for answers.  |
|
|
Posts:
3,533
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
21 Nov 18, 13:32
in response to: JeffTucker
|
|
|
|
Yes. I think the way to go currently is to use compiled Java for skin UIs and consider using Groovy or JavaScript (both compiles) for scriptlets.
|
|
|
Posts:
1,158
Registered:
14-Dec-2007
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
21 Nov 18, 19:09
in response to: davidekholm
|
|
|
Well I continued converting onload.bsh to onload,goovy for the FancyBox skin and I am making progress!
But now I get stuck with this message: Stack trace for jAlbum 17.1b5 using skin FancyBoxGroovy 1.3.3:
se.datadosen.util.ScriptException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script8.groovy: 94: unable to resolve class FocusListener
in onload.groovy at line number 94 at column number 16
at se.datadosen.util.ScriptException.of(ScriptException.java:59)
code starting at line 94: FocusListener fl = new FocusAdapter() {
private void focusLost(FocusEvent e) {
saveUI();
}
};
panoramicImage.addFocusListener(fl);
Can that be an import problem?
My imports are: import se.datadosen.component.*;
import se.datadosen.util.*;
import se.datadosen.jalbum.*;
import se.datadosen.jalbum.event.*;
import javax.swing.filechooser.*;
import se.datadosen.io.*;
import edu.stanford.ejalbert.*;
|
|
|
Posts:
3,918
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
21 Nov 18, 20:39
in response to: AndreWolff
|
|
|
Read this from the 17.1 beta thread. |
|
|
Posts:
8,357
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
21 Nov 18, 22:25
in response to: RobM
|
|
|
|
And of course, if you were working in NetBeans with a compiled UI, Fix Imports (CTRL-SHIFT-i) would simply bring in all the needed imports. No guesswork.
|
|
|
Posts:
3,918
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
21 Nov 18, 22:35
in response to: JeffTucker
|
|
|
And of course, if you were working in NetBeans with a compiled UI, Fix Imports (CTRL-SHIFT-i) would simply bring in all the needed imports. No guesswork.
Plus Groovy is experimental, even if a skin is converted it won't work unless jAlbum continues to support it or the skin provides instruction on how to add all of the dependencies required - ugh, perish the thought.
For now, I'm not progressing past playing with it by building small external tools. |
|
|
Posts:
8,357
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
21 Nov 18, 22:53
in response to: RobM
|
|
|
|
And the one thing that's been confirmed is that using Groovy for a skin UI is the worst of all worlds. Even slower than BeanShell. So that's a pointless exercise.
|
|
|
Posts:
3,918
Registered:
4-Aug-2006
|
|
|
Posts:
568
Registered:
30-Aug-2004
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
22 Nov 18, 01:15
in response to: RobM
|
|
|
|
|
|
Posts:
3,918
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum 17.1 beta for testing
Posted:
22 Nov 18, 10:21
in response to: jimberry
|
|
|
Sorry, there was a hidden control character at the end of the links, not sure if it was the copy or paste that introduced it. Now fixed. |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
