Compiling your skin's user interface has two advantages. First, the skin will load faster. For a skin with simple options, the difference isn't noticeable, but for a skin with a lot of panels and fields, it can make quite a difference. Second, working in an IDE like NetBeans will warn you about things like syntax errors, misspelled variable names, and so on, so that you can correct them before you ever compile the interface. With an interpreted onload.bsh, it's more a matter of "modify, see if it crashes when you load the skin, try to figure out why, modify again...."
So, some instructions, and the source files for a basic DemoSkin skin that can serve as a model. Pathnames assume Windows - in macOS, things naturally won't be in the same places. Questions? Please post them in Skin development.
Step one, installing the Java JDK, JavaFX SDK, and NetBeans.
Install OpenJDK 13: https://jdk.java.net/14/. This has no installers, alas. Unzip the file, and stash the extracted files in the same place your existing JDK folders are, like C:\Program Files\Java\.
Install OpenJFX SDK: https://gluonhq.com/products/javafx/. Scroll down a bit, and grab the version 14 release. Ditto on the lack of installers - unzip and move it to the same place your JDK's live.
You should end up with your JDK 14 stuff neatly organized in the same place - see screenshot winjdk.png. (I still have JRE 8 for another application - you don't need it.)
Download and install NetBeans from https://netbeans.org/. You can save some installation space by customizing the installation and de-selecting the PHP and Java EE modules, which aren't needed for compiling a jAlbum skin user interface.
Name the project - for example DemoSkin. If you want to name the project for your own skin instead, like MySkin, change all references in the following instructions and in the attached source files to match that name.
In the Projects pane, right-click DemoSkin, and choose Properties.
Under Sources, go to Source/Binary Format, and choose JDK 11. The skin will be compatible with jAlbum 17 or better.
Under Libraries, go to Java Platform, and choose JDK 14.
Under Libraries, Compile, click the plus sign next to Classpath, choose Add JAR/Folder, navigate to C:\Program Files\jAlbum\lib and choose jalbum-core.jar.
Click the plus sign next to Classpath again, choose Add JAR/Folder, navigate to C:\Program Files\Java\javafx-sdk-14\lib and choose javafx.graphics.jar.
Under Build, Packaging, check both Compress JAR File and Build JAR after Compiling.
OK out of Properties.
In the Projects pane, right-click Source Packages and choose New, Java Class.
Create a new Java class named DemoSkin and click Finish. Repeat, and create one named SkinModel.
If you're also going to create a custom UI panel, i.e., a panel for applying some settings to individual images or folders, which appears on the right side when you're in "edit" mode for an image or folder, create two more new Java classes, one named DemoSkinCustom and one named SlideModel. For a real-world example of a custom UI, see https://jgromit.com/pluto/man/pluto_image-specific.html.
Copy the contents of the attached source files to the appropriate source classes in NetBeans. You could, instead, exit NetBeans, then in Windows Explorer or Finder, replace the four files under NetBeansProjects\Sources\DemoSkin\src with the attached files.
In each of the source files you have just created, hit ALT-SHIFT-F to clean up the formatting.
Re: Compiling a skin's user interface
in response to: jGromit
Step four, taking your existing skin's UI and converting it.
You'll need to stash your original onload.bsh somewhere so that you can copy things out of it.
If you try to copy your entire existing onload.bsh into NetBeans, you'll be chasing down problems forever, without being able to compile the UI until all the errors are fixed. I would suggest, instead, that you tackle one of your existing panels at a time. Define the variables in the SkinModel.java source file (type and default value), then edit YourSkin.java to define the UI fields, set up the StateMonitor()'s (if any), and lay out the panel.
My example uses anonymous inner classes, which I find much easier to maintain - it lets you move things from one panel to another without having to edit every reference to a variable that's on the panel. No more ui.varName or panelName.varName. If you use anonymous inner classes in onload.bsh, skin loading can be very slow, but in a compiled UI it's not an issue.
A lot of things are pretty much the same in a compiled UI as they are in an interpreted one, though Java is fussier about things like data typing than BeanShell is.
At any time, you can clean up your formatting by hitting ALT-SHIFT-F. You can automatically insert any missing imports with CTRL-SHIFT-I.
When you're ready to compile (don't even try it if there are any red error markers in NetBeans - it won't compile), click the hammer icon on the toolbar. When compilation is complete, copy NetBeansProjects\YourSkin\dist\YourSkin.jar to your skin's lib directory.
Do my examples show the only way to do things, or even the absolute best way? Not at all. They just show how I'm doing things in my skins, and these approaches work for me. Keeping things grouped the way they are (field definitions, monitors, layout, etc.) tends to keep me out of "improperly nested hell." And yes, you will find yourself there at some stage of the game. One thing to remember - when you enter an opening curly brace in NetBeans, it will automatically supply the closing one. But control panel definitions also require a closing semi-colon, which you have to enter manually. So before you even start populating a control panel with fields, close the sucker - that will cut down on the "endless red markers" phenomenon.
If you're wondering how to do some of the fancier things you might see in my skin's UI's, the source files are all bundled with the skins - burrow down into the skin directory to find the files.
Re: Compiling a skin's user interface
in response to: jGromit
So, is this all worth the effort? Yes. Absolutely yes. The initial hurdle is large, but once you've done it, you're home-free. It is much easier to maintain a compiled UI than it is to maintain an interpreted onload.bsh.
You won't spend endless time hunting down the little typo that's preventing your skin from loading - in NetBeans, the second you mis-type a variable name, you'll get a red underline that alerts you to the error.
You won't have to head-scratch when your failure to include a toString() when you're checking a user choice causes mysterious errors. NetBeans will warn you about a data type mismatch.
And your skin will load in a fraction of the time.