This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 12 - Pages: 1 - Last Post: 22-Nov-2018 10:21 Last Post By: RobM Threads: [ Previous | Next ]
davidekholm

Posts: 3,573
Registered: 18-Oct-2002
jAlbum 17.1 beta for testing
Posted: 16-Nov-2018 14:39
 
  Click to reply to this thread Reply
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" }
AndreWolff

Posts: 1,715
Registered: 14-Dec-2007
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 11:54   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
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.
davidekholm

Posts: 3,573
Registered: 18-Oct-2002
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 12:09   in response to: AndreWolff in response to: AndreWolff
 
  Click to reply to this thread Reply
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.
jGromit

Posts: 7,494
Registered: 31-Jan-2006
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 13:16   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
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. ;)
davidekholm

Posts: 3,573
Registered: 18-Oct-2002
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 13:32   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
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.
AndreWolff

Posts: 1,715
Registered: 14-Dec-2007
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 19:09   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
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.*;
RobM

Posts: 3,115
Registered: 4-Aug-2006
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 20:39   in response to: AndreWolff in response to: AndreWolff
 
  Click to reply to this thread Reply
Read this from the 17.1 beta thread.
jGromit

Posts: 7,494
Registered: 31-Jan-2006
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 22:25   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
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.
RobM

Posts: 3,115
Registered: 4-Aug-2006
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 22:35   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
jGromit wrote:
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.
jGromit

Posts: 7,494
Registered: 31-Jan-2006
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 22:53   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
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.
RobM

Posts: 3,115
Registered: 4-Aug-2006
Re: jAlbum 17.1 beta for testing
Posted: 21-Nov-2018 23:37   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
jGromit wrote:
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.
Some background on how Groovy came up as a possible alternative language:
Originally mentioned in 2014 under Playing with other scripting languages

Most recently mentioned in New support class for long running tasks

Note the reference that Groovy used to be supported by Netbeans, as a built-in plugin, maybe it will again.

Edited by: RobM on 22-Nov-2018 09:17
Removed hidden character from end of links
jimberry

Posts: 503
Registered: 30-Aug-2004
Re: jAlbum 17.1 beta for testing
Posted: 22-Nov-2018 01:15   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
When clicking on your links I get a "not found" message, although the link addresses seem to work -
http://jalbum.net/forum/thread.jspa?messageID=292299&#292299
http://jalbum.net/forum/thread.jspa?messageID=329914&#329914
RobM

Posts: 3,115
Registered: 4-Aug-2006
Re: jAlbum 17.1 beta for testing
Posted: 22-Nov-2018 10:21   in response to: jimberry in response to: jimberry
 
  Click to reply to this thread Reply
jimberry wrote:
When clicking on your links I get a "not found" message, although the link addresses seem to work -
http://jalbum.net/forum/thread.jspa?messageID=292299&#292299
http://jalbum.net/forum/thread.jspa?messageID=329914&#329914
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

Point your RSS reader here for a feed of the latest messages in all forums