Hi everyone,

For jAlbum 13.4 we will support web based skin settings user interfaces!

Advantages:

• No need for Java/BeanShell knowledge in order to develop skins. Developers can rely on html+css+javascript knowledge only
• Better debugging environment. No unreadable BeanShell error messages. Skins can be tested in your ordinary web browser and debugger

For this to work, you only need to fit your skin with a "ui.html" file. (No "onload.bsh" or "onload.js" files). jAlbum will present the skins's UI in an embedded web browser. Named input elements embedded in a <form> element will have their data passed back and forth as jAlbum variables automatically.

We do support JavaScript's "alert", "confirm" and "prompt" functions (also works in the embedded web browser for previews). Debug prints passed to console.log ends up in jAlbum's system console. Links to external sites should have a target="_blank" attribute and are then opened in separate browser windows.

Eager to try? Ensure you run jAlbum 13.3, then patch your lib/jalbum-core.jar with this one . Finally install and play with the attached MinimalWeb.jaskin file. This somewhat older version of Minimal uses the jQuery and jQueryUI libraries to simplify styling and disabling of input elements.

Current limitations:

• No support for multilingual skins yet
• Color picker not working yet. Will work when Java 8 u112 is released in October. Testers can run jAlbum on an early version of u112 already, available via http://java.oracle.com

Hints: You can now use CTRL/CMD+R to reload the skin quickly. You can also right click the skin's UI and select "Reload" from the popup menu in order to reload the page only (setting it to default state)

It is my hope that this change will ten-fold the potential developer base for jAlbum skins as you "only" need to be proficient in html, css and JavaScript.

What do you think?

Screenshot:

Yes, you can skip jQuery altogether. It helps styling components so they (in my opinion) look better. It also makes the components behave better. The spinner control doesn't for instance have up/down buttons in the embedded browser, but with jQuery it gets them.

Intriguing. It certainly makes some things considerably simpler, while also providing more flexibility than RiverLayout (getting boxes to line up, for example, often requires multiply-nested layers of ControlPanel()'s - a lot simpler with HTML/CSS).

Do we need to learn Spanish to use tabs.css?

From what I'm seeing, I gather that default values are all set within the form layout, so there's no SkinModel.java, correct?

I'm loathe to wade into unreleased Java, but will the color selector support include the kinds of things we have now, like multiple chooser methods (HSV, HSL, RGB, etc.), and semi-transparency? And how about the current linked "color box and hex code" entries?

Lots of unanswered questions, of course, like how to handle custom UI's - not just the simple "tab in Edit mode," like Gromit, but also the "entire popup tabbed window" like Matrix.

Context-sensitive help?

Any idea what loading speed might be like? I was driven into a compiled UI in Matrix (thankfully - it's been much easier to manage than an interpreted onload.bsh) because the loading time was hitting the 30-second mark. It was painful. I'd hate to go backwards on that aspect of things.

Yes, hoping so too.

They does look a bit odd in the html code as there is no inherent support for tabs in html, but peek at the sample code for a while and I think you get the hang of it. There is probably a lot of "magic" happening inside jQueryUI. Perhaps similar can be achieved with a clever us of style sheets only? There is no lack of web based frameworks and techniques out there. Please investigate and share your best solutions so we can point skin developers in good ways forward.

You can still use a SkinModel if you like typed (not just all strings) defaults when running in a command line mode.

The color selector looks really fine. It has both HSV, HSL and RGB, but is actually missing semi transparency. This looks like a W3C standards limitation. Presenting hex values next to the selectors would also require some jQuery or JavaScript magic I take it. This is the downside with web technology: You get a default set of standardized components. If you want to extend that, they have to be rolled using JavaScript. With plain Java UIs (or JavaFX) UIs, both the standard and extended components are all Java objects.


Bring them on


Needs to be implemented with some JavaScript I guess. I hope we can work out our point developers to suitable JavaScript libraries for such things soon. Let's all work together on that.


Very relevant question. I assume loading speed will be really good actually. Although few things beats the performance of a Java UI, it's mostly up to how you code the JavaScript of a web based UI. JavaScript in itself, especially the dead fast "Nashorn" JavaScript engine Java 8 uses is orders of magnitudes faster than BeanShell. The WebView browser is based on WebKit and should have decent performance: http://stackoverflow.com/questions/10762979/performance-of-webview-in-javafx

Correction: I suspect Oracle is still using the JavaScript engine that comes with WebKit for the browser. At least according to http://sjhannah.com/blog/?p=404

An advice. If you're happily coding your skin's UI using compiled Java+Swing, continue doing so. This move is mainly made to lower the entry barrier to skin development for those who don't know Java.

I mean this link panel in the Slide Show 4 skin.
Can this be made as well?

Edited by: AndreWolff on 14-Aug-2016 08:45

You can read those within init.js, do you need access to stuff like page linking, rows and cols in the skin's UI too? (suitable defaults can be set using hints.jap)