A couple of days ago there was an announcement on this blog about jSilhouette's 0.1 release, followed by a comparison between the geom, scene and jfx demos (regular Java, Project SceneGraph and JavaFx Script each).

Things have changed a bit. Jacek Furmankiewicz brought to my attention that Project SceneGraph is licensed under GPLv2 (no classpath extension) which means both jsilhouette-scene and jsilhouette-jfx must use the same licensing scheme. But jsilhouette-geom does not, in fact it has been re-licensed to ASL 2.0, this means that starting with the next release commercial use of jsilhouette-geom is no longer a problem. The commercial usefulness of the remaining modules lies in Sun's will to re-license Project SceneGraph to GPLv2 with classpath extension.

Some other updates

• Donut shape has been added to all modules. Donuts may be circular or polygonal.
• Default values have been added to some attributes in the jfx module, alleviating the pain of setting each attribute.
• Groovy demo (GraphicsBuilder based) available!

Here is an screenshot on the latest demo app



Nice Nimbus look &feel, you may be thinking that this is the new version of the jfx demo, but it is not! this is the Groovy version (ShapesDemoGroovy.groovy) , the green color is darker in jfx, remember? let's revisit the stats, shall we?

	geom	scene	jfx	groovy
LoC	369	505	619	369
Tokens	1486	1855	2644	2194
Source file size (bytes)	16412	21000	20626	15311
Compiled code size (bytes)	104K	60K	76K	92K

The Groovy version beats the JavaFx Script version in almost all categories (the source file is even shorter than the Java2D version) but these numbers do not reflect how small the code can be in each version. For example I discovered that the jfx version has some commas (,) between attribute declaration (which bump the char and file size), I was surprisewd to find out JavaFx Script was happy with them as not even a slight warning is given by the compiler, nice!; the Groovy version harnesses the power of native syntax for Lists and Maps to reduce variable declaration; defaults values are not really used that much in all versions.

I also mentioned previously that making the second and third demo was quicker once the first one was done, in this case it was no different. The jfx version was copied almost verbatim, added some Groovy sugar here and there (even had to add a MetaClass hack due to how SwingBuilder handles look&feel in the 1.5.6 version (the new one is slicker thank @shemnon for that)). Quick comparison between how the jfx and groovy versions initialize the frame, first the jfx one
SwingFrame { title: "jSilhouette Shapes (JavaFX)" visible: true closeAction: function() { System.exit(0); } width: 500 height: 400 content: BorderPanel { center: canvas /*an instance of Canvas*/ left: GridPanel { columns: 1 rows: 10 content: [ SwingButton { text: "Arrow" action: drawArrows }, SwingButton { text: "Balloon" action: drawBalloons }, SwingButton { text: "Cross" action: drawCrosses }, SwingButton { text: "Donut" action: drawDonuts }, SwingButton { text: "MultiRoundRectangle" action: drawMultiRoundRectangles }, SwingButton { text: "Rays" action: drawRays }, SwingButton { text: "RegularPolygon" action: drawRegularPolygons }, SwingButton { text: "RoundPin" action: drawRoundPins }, SwingButton { text: "Star2" action: drawStars }, SwingButton { text: "Triangle" action: drawTriangles } ] } } }
Where each draw* function is of the form
var canvas: Canvas = Canvas { } var drawArrows = function():Void { canvas.content = [ Arrow { x: 20 y: 20 width: 100 height: 60 rise: 0.5 depth: 0.5 fill: Color.RED stroke: Color.BLACK }, ... ] }
Here I'd like to take the opportunity to mention that the function signature must have Void as its return type otherwise a compilation error will be thrown. If the return type is not specified then it will be the same type of the last evaluated expression, in this case Node[], SwingButton expects its action function to return Void. I'm sure a tool (like NetBeans' jfx plugin) would have drawn a red underline/popped an error/whatever under the offending code before attempting a full compile on the code by myself, but I went with the "manual" way: Vim + command line compiler, so there, had to be more careful

Here is the Groovy version
/* Groovy 1.5.6- hack */ SwingBuilder.metaClass.lookAndFeel = { List lafs -> for( laf in lafs ) { try{ delegate.lookAndFeel(laf); break } catch( ex ) {/* ignore */} } } SwingBuilder.build { lookAndFeel( ['nimbus', 'mac', 'gtk', 'metal'] ) frame( title: 'jSilhouette Shapes (Groovy)', size: [500,400], defaultCloseOperation: JFrame.EXIT_ON_CLOSE, show: true, locationRelativeTo: null ) { borderLayout() panel( new GraphicsPanel(), id: 'canvas', constraints: BL.CENTER ) panel( constraints: BL.WEST) { gridLayout( columns: 1, rows: shapes.size() ) shapes.each { shape, graphicsOperation -> button( shape, actionPerformed: { evt -> def group = gb.group( borderColor: 'black' ) group << gb.antialias(true) group << graphicsOperation canvas.graphicsOperation = group }) } } } }
Where shapes is a Map initialized like
def gb = new GraphicsBuilder() def shapes = [ 'Arrow': gb.group { arrow( x: 20, y: 20, width: 100, height: 60, rise: 0.5, depth: 0.5, fill: 'red' ) }, ... ]
The Groovy version requires some 'plumbing'

• Fix SwingBuilder.lookAndFeel to accept a List of L&F identifiers (available in Groovy 1.6.x).
• Set the preferred L&F.
• Tell the frame where it should be located by default (locationRelativeTo: null)

The native syntax for Lists and Maps comes in our aid here. Iterating each entry (String,GraphicsOperation) it is a matter of hooking up the proper values on the button's text and action. Notice that each time a button is clicked a new GraphicsOperation is created (a group) that has a 'global' property applied to all its children (borderColor: 'black') and antialias is turned on. GraphicsPanel is smart enough to know when it should repaint itself (similar to JSGPanel and Canvas). Of course some would say you may iterate over a sequence in the jfx version in order to build the buttons in a loop, sure you can. You could also create a java.util.Map that holds each label and related function, but the code is not as concise as the Groovy one. Assuming hypothetical classes javafx.util.LinkedHashMap and javafx.util.MapEntry
var shapes = LinkedHashMap { content: [ MapEntry { key: 'Arrow' value : [ Arrow { ... }, ... ] }, ... ] } ... shapes.eachEntry ( function(key:Object,value:Object):Void { var label = key as String; var actionFunc = value as Function; // (???) var button = SwingButton { text: label, action: actionFunc } // insert button in its proper place })Yup, hypothetical is more like it (my code that is, still have to learn more about JavaFx Script) but you get the idea. Back to jSilhouette, I'd like to have proper javadocs/javafxdocs in place before releasing the next version, so it will take a couple of days more.

Feedback is always appreciated.