Andres Almiray's Weblog

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 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?



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' 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.

graphics graphicsbuilder groovy java java2d javafx jfx jsilhouette

jSilhouette includes a demo application for each one of its subprojects (geom, scene & jfx) showing the shapes in action. This post is a recollection of what happened during the time those applications were developed and what lessons I learned while doing so.

Let's start with some screenshots, both jsilhouette-geom and jsilhouette-scene use the default Swing settings (which means ugly Metal L&F), from an outsider's point of view there is no difference whatsoever on the finished app so the following screenshot is the same for both demo apps



The real difference strives in how the graphics are attached to the canvas panel. Regular Swing/Java2D applications that rely on custom painting usually create a subclass of JComponent or JPanel and plug-in the custom painting code. This is exactly what ShapesDemoJava.java does, it defines a CanvasPanel that requires and instance of PaintOperation to actually draw anything as its contents. Each button wires up a listener that creates an anonymous inner implementation of PaintOperation upon activation. In other words quite the regular plumbing we are used to in Swing/Java2D.

Now on the SceneGraph version (ShapesDemoSG.java) things look a bit brighter. SceneGraph relies on SGNode to do its work, happily for us it also includes a handy JSGPanel that knows how to render SGNodes, in other words, you do not need to create a CanvasPanel nor a PaintOperation, just make sure to build a proper graph of SGNodes and set it as the scene property of a JSGPanel instance. Notice that in both demo apps the main frame and the whole ui are built in the EDT (thanks to wrapping the building code with SwingUtilities.invokeLater), this is important to remark as the next demo relieves you of that burden: ShapesDemoFX.fx. The JavaFx Script libraries also provide a canvas, aptly named Canvas, where you can set a sequence of Node instances as its content, which will be used to draw anything into it. Declarative programming helps a bit in reducing the visual clutter (no setter/getters) but in no way reduces the amount of lines of code (more on that later). So how does it look?



If you run the demos with j6u10 installed you'll get a nicer L&F (Nimbus), the frame will be centered on the screen by default too. Notice that the green color differs form one screenshot to the other, I don't know why but java.awt.Color.GREEN is lighter that javafx.scene.paint.Color.GREEN.

Time for some stats. I have no recorded data on the time spent in each demo app, what it is true is that I started with the geom demo and finished with the jfx one. Once the first layout and behavior was set, the other two demo apps were quicker to implement (already had the recipe), it was just a matter of using the native facilities of each version. Lines of Code is also another metric people like to use, along with the size of the packaged product, here goes


Looks like the geom version is the winner in terms of LoC & Tokens and the jfx is a considerable percentage behind, but there is some explaining involved. Even though the geom version creates its own 'rendering setup' it also relies on specialized constructors available in each shape, so creating a shape with a mix of default values and new ones is just a matter of invoking a one-liner. The scene version requires less plumbing on the 'rendering setup' (as explained before) but its shapes do not provide specialized constructors, which means that if those constructors were available this version should be the shortest one in terms of LoC), thus requiring helper methods to build each shape. Lastly the jfx version does not require any specialized 'rendering setup' (it is already there), so it is the declarative way of instantiating an object the one responsible for the amount of LoC and Tokens. Notice that many properties are clumped in the same line (contrary to many jfx demos out there) effectively rendering the LoC argument quite pointless, that is why I decided to also show the token count.

So is declarative programming bad for your productivity? certainly not. What we 'lost' in source file size we gained in comprehensibility and readability. The jfx version explicitly states which property has what value, in the geom/scene versions you will have to search the code to know the correct order and types of the parameters (this is where tool support kicks in, right?).

Regarding file size, the geom shapes provide accessors for each property and the actual implementation of each shape, the scene shapes provide only accessors for each property and rely on their correspondent shape (of the geom package) making them smaller. The jfx version is bigger given that The second rule should not be unknown to Groovy developers, after all triggers in jfx are functions, similar to Groovy's closures (I say similar but not identical, will explain that on another post); Groovy's closures are compiled to their own classes too. Some may say "what about compressing with pack2k? that will reduce the size of the jfx package", sure and that will reduce the size of the others too, so the size-ratio will be retained.

What about the Groovy version? I'm a bit embarrassed as it is not finished yet but here is a glimpse of how it may look
import groovy.swing.SwingBuilder import groovy.swing.j2d.GraphicsBuilder import groovy.swing.j2d.GraphicsPanel import java.awt.BorderLayout as BL 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', borderColor: 'black' ) }, ] SwingBuilder.build { frame( title: 'jSilhouette Shapes (Groovy)', size: [500,400], show: true ) { borderLayout() widget( 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 -> canvas.graphicsOperation = graphicsOperation }) } } } } Other than requiring an explicit GraphicsBuilder instance (that will probably change in the future *wink*) this version as a bit shorter on the build code as the native Map syntax is really helpful here, but I believe the token count may be a bit bigger than the jfx version given that commas are required to separate each property when declaring the shapes.

graphics graphicsbuilder groovy java java2d javafx jfx jsilhouette

I'm pleased to announce the release of jSilhouette 0.1, a collection of Java2D shapes. Any of you that have followed this blog on the past knows that GraphicsBuilder bundles additional shapes to the set found in the java.awt.geom package, like Arrow and Cross, well jSilhouette provides those additional shapes sans Groovy, i.e, in a standalone distribution (GraphicsBuilder will be retrofitted to use the new package). This means the following shapes are now at your disposal: Arrow, Balloon, Cross, MultiRoundRectangle, Rays, RegularPolygon, RoundPin, Star and Triangle (some examples here, here and here). But wait, there is more! jSilhouette also includes SceneGraph and JavaFx Script friendly distributions.

jSilhouette is available under GPLv2 with classpath extension, the same license used by Java and JavaFx Script.

Feedback is always appreciated.

announcement graphics graphicsbuilder groovy java java2d javafx jfx jsilhouette

I'm pleased to announce that version 0.2 of the J2D plugin for Grails has been released. This version adds support for SVG output and image caching. It also solves a terrible problem that rendered the previous version quite unusable in reloading scenarios.

In order to cache an image you will have to specify two new parameters Feedback is always appreciated

Keep on Groovying!

grails graphics graphicsbuilder groovy j2d plugin

I'm pleased to announce that GraphicsBuilder 0.6 has been released. It has many updates and finally makes public both SVGRenderer and SWFRenderer. Here are a couple of posts that describe what's included in this release: The doc site has been updated with an alphabetical index of all available nodes and their properties.

Feedback is always appreciated.

Keep on Groovying!

graphics graphicsbuilder groovy java2d swing

Continuing with the Substance related additions, it is now possible to use Fractal Flames as texture filters. I was very impressed by Kirill's demo on Fractal Flames, even wanted to add them to GraphicsBuilder ASAP. Well it took a bit longer than that but now it is done. Check it out



// background rect( w: 220, h: 160, f: 'black' ) { filters { fractalFlame( colorScheme1: sunfireRedColorScheme, ifs: singularityIFS, iterations: 2000000 ) } } // save butterfly as shape butterflyShape( x: 10, y: 10, w: 200, h: 140, s: true, id: 'butterfly' ) // apply butterfly as clip clip( shape: butterfly ) // draw butterfly draw( shape: butterfly, keepTrans: yes, f: 'black' ){ filters { fractalFlame( colorScheme1: colorScheme("lime green"), ifs: kaleidoscopeIFS, iterations: 2000000 ) } } Fractal Flames require SubstanceColorSchemes in order to work, you can reference a predefined one using smart builder variables, like limeGreenColorScheme (which is actually an instance of LimeGreenColorScheme); you may also use the colorScheme node, which will automagically translate its value into a predefined SubstanceColorScheme. The following are equivalent calls for obtaining a LimeGreenColorScheme As Kirill notes, generating a fractal flame is a costly operation, depending on the number of iterations and the type of function (IterativeFunctionSystem) that you use to generate them. This filter will try its best to keep a cached result of the generated fractal, calculating it again only when a visible property has changed value.

Keep on Groovying!

graphics graphicsbuilder groovy substance

Kirill has been busy lately updating Substance with new features, a recent post on his blog shows button shapers in action. Suddenly realized that supporting those shapes in GraphicsBuilder would be quite easy, and so graphicsbuilder-ext-substance was born. Here is a sample image



Once the shapers were wrapped with a ShapeGraphicsOperation (actually just one shaper was required) the rest of the work was just wiring property aliases. Here is the code that produced the image
antialias on dolphinShape( x: 10, y: 10, w: 120, h: 80, borderColor: no ){ gradientPaint( x2:0, y2: 50, c2: 'blue' ) } rhinoShape( x: 140, y: 10, w: 120, h: 80, bc: no ){ gradientPaint( x2:0, y2: 50, c2: 'darkGreen' ) } raceCarShape( x: 35, y: 90, w: 200, h: 80, bc: no ){ linearGradient( x2: 0, y2: 50 ) { stop( s: 0, c: 'yellow' ) stop( s: 0.6, c: 'red' ) stop( s: 0.9, c: 'black' ) } }
You can find other goodies in the Substance Extras pack, like fractal flames. Imagine a filter based on those

Keep on Groovying!

graphics graphicsbuilder groovy

GraphicsBuilder has had SVG support for some time ago, but it only supported transforming SVG documents into groovy code. Not anymore! it now is capable of writing SVG documents too, thanks to SVGRenderer. I must confess that Batik is the real workhorse here, as it provides a very handy SVGGraphics2D class (a subclass of Graphics2D), writing svg is just a matter of pluggin an instance of that class into a GraphicsContext, execute the code and write the result. To show you how easy it is here is the previous SWFRenderer example but with SVG this time
import groovy.swing.j2d.* import groovy.swing.j2d.svg.* def go = { antialias true rect( x: 50, y: 50, w: 100, h: 100, f: 'red', bc: 'darkRed' ) rect( x: 10, y: 10, w: 100, h: 100, f: 'blue', bc: 'navy' ) circle( cx: 150, cy: 150, r: 40, f: 'orange', bc: 'darkOrange' ) star( cx: 100, cy: 100, or: 50, ir: 20, f: 'green', bc: 'darkGreen' ) } def gr = new GraphicsRenderer() def sr = new SVGRenderer() gr.renderToFile( "/tmp/out.png", 200, 200, go ) sr.renderToFile( "/tmp/out.svg", 200, 200, go )
This code produces the following SVG output
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.0//EN' 'http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd'> <svg stroke-dasharray="none" shape-rendering="auto" xmlns="http://www.w3.org/2000/svg" font-family="'Dialog'" width="200" text-rendering="auto" fill-opacity="1" contentScriptType="text/ecmascript" color-interpolation="auto" color-rendering="auto" preserveAspectRatio="xMidYMid meet" font-size="12" fill="black" xmlns_xlink="http://www.w3.org/1999/xlink" stroke="black" image-rendering="auto" stroke-miterlimit="10" zoomAndPan="magnify" version="1.0" stroke-linecap="square" stroke-linejoin="miter" contentStyleType="text/css" font-style="normal" height="200" stroke-width="1" stroke-dashoffset="0" font-weight="normal" stroke-opacity="1"> <!--Generated by the Batik Graphics2D SVG Generator--> <defs id="genericDefs"/> <g> <defs id="defs1"> <clipPath clipPathUnits="userSpaceOnUse" id="clipPath1"> <path d="M0 0 L200 0 L200 200 L0 200 L0 0 Z"/> </clipPath> </defs> <g fill="red" text-rendering="optimizeLegibility" stroke="red"> <rect x="50" width="100" height="100" y="50" clip-path="url(#clipPath1)" stroke="none"/> <rect x="50" y="50" clip-path="url(#clipPath1)" fill="none" width="100" height="100" stroke="rgb(139,0,0)"/> </g> <g fill="blue" text-rendering="optimizeLegibility" stroke="blue"> <rect x="10" width="100" height="100" y="10" clip-path="url(#clipPath1)" stroke="none"/> <rect x="10" y="10" clip-path="url(#clipPath1)" fill="none" width="100" height="100" stroke="rgb(0,0,50)"/> </g> <g fill="rgb(255,200,0)" text-rendering="optimizeLegibility" stroke="rgb(255,200,0)"> <circle r="40" clip-path="url(#clipPath1)" cx="150" cy="150" stroke="none"/> <circle fill="none" r="40" clip-path="url(#clipPath1)" cx="150" cy="150" stroke="rgb(255,140,0)"/> </g> <g fill="lime" text-rendering="optimizeLegibility" stroke="lime"> <path d="M100 50 L88.2443 83.8197 L52.4472 84.5491 L80.9789 106.1803 L70.6107 140.4509 L100 120 L129.3893 140.4509 L119.0211 106.1803 L147.5528 84.5491 L111.7557 83.8197 Z" clip-path="url(#clipPath1)" stroke="none"/> <path fill="none" d="M100 50 L88.2443 83.8197 L52.4472 84.5491 L80.9789 106.1803 L70.6107 140.4509 L100 120 L129.3893 140.4509 L119.0211 106.1803 L147.5528 84.5491 L111.7557 83.8197 Z" clip-path="url(#clipPath1)" stroke="rgb(0,100,0)"/> </g> </g> </svg>
Because SVGRenderer uses a Graphics2D subclass all other nodes are automatically supported, this means gradients, filters, images, ... neat!

Keep on Groovying!

graphics graphicsbuilder groovy svg

The initial announcement of SWF support in GraphicsBuilder was well received, I decided to follow João's advice and switch from Ming to Transform SWF, as Ming is quite behind in the feature department and Transform has been updated constantly and recently.

Here is a very basic example of SWFRenderer in action, as it only supports groups, shapes and outlines for the time being (basic fills, no fancy paints), the image on the right was produced by GraphicsRenderer, the one on the left by SWFRenderer (you can tell because it uses Flash's plugin )


You may be wondering about the code, so here it is
import groovy.swing.j2d.* import groovy.swing.j2d.swf.* def go = { antialias true rect( x: 50, y: 50, w: 100, h: 100, f: 'red', bc: 'darkRed' ) rect( x: 10, y: 10, w: 100, h: 100, f: 'blue', bc: 'navy' ) circle( cx: 150, cy: 150, r: 40, f: 'orange', bc: 'darkOrange' ) star( cx: 100, cy: 100, or: 50, ir: 20, f: 'green', bc: 'darkGreen' ) } def gr = new GraphicsRenderer() def swfr = new SWFRenderer() gr.renderToFile( "/tmp/out.png", 200, 200, go ) swfr.renderToFile( "/tmp/out", 200, 200, go )
No extra nodes required for SWF rendering so far, but I guess as the renderer gets fancier it may support SWF only nodes. SWFRenderer accepts optional settings like background color and frameRate, but I'll show how to use them in a later post. There is a "side-effect" from switching to TransformSWF, that library is able to read SWF files by creating an internal model, which although it is a bit tangled at first (the SWF model that is), may enable importing SWF drawings into GraphicsBuilder's drawings ...

Keep on Groovying!

graphics graphicsbuilder groovy swf

It was bound to happen, once I rediscovered the Ming library through vnc2swf while making screencasts I knew I had the tools to output SWF files using GraphicsBuilder.

Ming offers various language bindings, fortunately one of them is Java, problem is that Ming is currently on 0.4beta but the java extension is on 0.3. Another problem that I found (which was quite annoying) is that the java extension declares all its classes in the default package, somehow making Eclipse & Maven complain while importing the classes. Lastly that extension is built using a Makefile, which may be understandable from the point of view that it is really old code and that it has some native code too.

So the first task was putting ming-java up to date, rolling an Ant based build, even enabling native compilation through the cpptasks from ant-contrib; also moved the classes to net.sf.ming package so no more import conflicts. The code seems to be tied to linux but I believe it may be possible to compile the native library for other OSes.

On the Groovy side, there is a new extension called graphicsbuilder-ext-swf which is responsible for converting from Groovy to SWF, the really good news? you can use the same syntax, the same nodes, nothing has changed This extension has put into evidence some pain points in the API that may also help in making groovy2svg (might as well finish the other side too, right?). Right now it supports transforming basic shapes and color fills, more to come later.

Keep on Groovying!

graphics graphicsbuilder groovy swf

When I wrote Groodle #3 I mentioned that JavaFX had a better syntax to enable and handle dragging of a shape, GraphicsBuilder's version is definitely more verbose but allows you to drag shapes, images and groups. Well not anymore, now all displayable nodes have a new property autoDrag, that when set to true will allow dragging of said displayable. The actual code is exactly the same but it allows you to set additional behavior and react to a displayable being dragged. Groodle #3 can be updated as follows
// goatee triangle( x: 60, y: 210, w: 40, angle: 180, f: 'brown', id: 'goatee', autoDrag: yes ){ filters { dropShadow( name: 'shadow', enabled: no ) } } ... def startDrag = { e -> def shape = e.target shape.borderWidth = 3 shape.borderColor = 'red' shape.filters['shadow'].enabled = true } def endDrag = { e -> def shape = e.target shape.borderWidth = 1 shape.borderColor = 'black' shape.filters['shadow'].enabled = false }
I also updated the code to follow Joshy's version, now that dropShadow and reflection (from Swingx) are also available as filters, I can finally render a shadow whenever a piece of clothing is dragged. Instead of creating a new filter each time (as in the jfx version) the shadow filter's enabled state changes according to the situation.

Screencasts of all Groodles are available too (thanks to vnc2swf, I love being back to Linux)
Keep on Groovying!

graphics graphicsbuilder groovy

Back to Joshy's latest doodle, I managed to get something out after meddling with GraphicsBuilder's recent updates. So here goes



There were some minor problems along the way, like shadow filter not working as expected (this filter is not based on the one provided by Swingx), that is why I choose to use shapes instead of images, updating the border while dragging instead of applying a shadow filter.

Let's step into each element of this groodle, first we will look at each shape, starting with the frog face. If it looks familiar is because it is based on the multipaint sphere example
def width = 150 def height = 150 def cx = width/2 + 10 def cy = height/2 + 10 antialias on group( name: "frogface" ){ circle( cx: cx, cy: cx, r: width/2, bc: no ){ multiPaint { colorPaint( color('green') ) radialGradient( cx: cx, cy: cy, r: width/2 ) { stop( s: 0, c: color(r: 6, g: 160, b: 76, a: 127) ) stop( s: 1, c: color(a: 204) ) } radialGradient( cx: cx, cy: cy, fx: 55, fy: 35, r: width/1.4 ){ stop( s: 0, c: color('white').derive(a:0.5) ) stop( s: 0.5, c: color('white').derive(a:0) ) } } } // left eye circle( cx: 40, cy: 50, r: 20, bc: 'black', f: 'white' ) circle( cx: 43, cy: 53, r: 12, bc: 'none', f: 'black' ) // right eye circle( cx: 130, cy: 50, r: 20, bc: 'black', f: 'white' ) circle( cx: 127, cy: 53, r: 12, bc: 'none', f: 'black' ) // nostrils circle( cx: 75, cy: 80, r: 4, bc: 'black', f: 'black' ) circle( cx: 95, cy: 80, r: 4, bc: 'black', f: 'black' ) // mouth ellipse( cx: 85, cy: 120, rx: 30, ry: 10, bc: 'black', f: 'black' ){ transformations { rotate( x: 85, y: 120, angle: -10 ) } } transformations { translate( x: 250, y: 60 ) } } Well, that was easy, now for each draggable piece of clothing. They are simple shapes, some area operations, and the hat has a pair of filters to give it a little depth (these pieces of clothing are not as nice as Joshy's hand drawn ones)
// eye patch add( bc: 'black', f: 'black', id: 'eyepatch' ) { rect( x: 10, y: 55, w: 150, h: 12 ) circle( cx: 40, cy: 80, r: 20 ) } // goatee triangle( x: 60, y: 210, w: 40, angle: 180, f: 'brown', id: 'goatee' ) // moustache add( f: 'brown', id: 'moustache' ){ ellipse( cx: 65, cy: 140, rx: 25, ry: 8 ){ transformations { rotate( x: 65, y: 140, angle: -12 ) } } ellipse( cx: 105, cy: 140, rx: 25, ry: 8 ){ transformations { rotate( x: 105, y: 140, angle: 12 ) } } } // hat add( f: 'orange', id: 'hat' ){ triangle( x: 70, y: 230, w: 140, h: 40 ) rect( x: 100, y: 180, w: 80, h: 40 ) filters { shapeBurst( merge: true, type: 'up' ){ linearColormap( color1: color('orange').darker(), color2: 'orange' ) } lights() } }
One last touch before ending the build closure is attaching a Swing button (not shown in the image) that will reset the position of all pieces of clothing. Thanks to Groovy's closures and having ids associated with each piece the code is pretty straight forward.
swingView { button( 'Reset', x: 5, y: 5, actionPerformed: {e -> ['eyepatch','goatee','moustache','hat'].each { gb."$it".txs.clear() } }) }
We reuse the each/closure trick outside the building closure to assign the mouse event handlers to each piece
['eyepatch','goatee','moustache','hat'].each { def shape = gb."$it" shape.mouseDragged = dragShape shape.mousePressed = startDrag shape.mouseReleased = endDrag shape.mouseExited = endDrag }
Alright, so now we must define 3 closures to handle each event and then we are done, right? well almost. It turns out it is not so easy to do drag&,drop with gfx, at least not in as many lines as its jfx counterpart, because as of today d&d support is not automatically included. If you look closely at the jfx example you will notice that it is just a matter of binding e.dragTransition.[x,y], hopefully it will be too in gfx during the next days. For now let me show you how it is done, there is definitely room for improvement so if anyone notices something please let me know!
def dragShape = { e -> def shape = e.target def bounds = shape.bounds def location = shape.props.location def dx = e.event.x - shape.props.dragPoint.x def dy = e.event.y - shape.props.dragPoint.y if( !shape.props.dragging ){ // start of drag if( !shape.txs['location'] ){ shape.txs << gb.translate( name: 'location', x: location.x, y: location.y ) }else{ shape.txs['location'].x = location.x shape.txs['location'].y = location.y } shape.props.dragging = true } if( !shape.txs['drag'] ){ shape.txs << gb.translate( name: 'drag', x: dx, y: dy ) }else{ shape.txs['drag'].x = dx shape.txs['drag'].y = dy } } def startDrag = { e -> def shape = e.target def bounds = shape.bounds if( !shape.props.anchor ){ shape.props.anchor = [x:bounds.x,y:bounds.y] } if( !shape.props.location ){ shape.props.location = [x:0,y:0] }else{ shape.props.location = [ x: bounds.x - shape.props.anchor.x, y: bounds.y - shape.props.anchor.y ] } shape.props.dragPoint = [x:e.event.x,y:e.event.y] shape.borderWidth = 3 shape.borderColor = 'red' } def endDrag = { e -> def shape = e.target shape.props.dragging = false shape.borderWidth = 1 shape.borderColor = 'black' }
As you can see the code is a bit verbose right now but it gets the job done, looks similar to the revisited dragging example previously posted. I have posted the code for this and the other groodles here, you can take them for a spin as soon as GraphicsBuilder 0.5 is released.

Keep on Groovying!

graphics graphicsbuilder groovy javafx jfx

Joshy has posted Doodle #3, a basic yet interesting make-your-character demo using JavaFX. The interesting part being that the demo displays draggable images, I'm so happy I revamped event handling recently, but before getting to work with Groodle #3 I'd like to present a couple of new things you can do with GraphicsBuilder. Suppose you have the following Gfx demo running



there are 3 "shapes", actually the green square pair is a group, here is the relevant code
rect( x: 10, y: 10, w: 40, h: 40, f: 'blue', mouseDragged: dragMe ) star( cx: 150, cy: 100, or: 40, ir: 20, f: 'red', mouseDragged: dragMe ) group( mouseDragged: dragMe ) { viewBox( x: 20, y: 100, w: 51, h: 51 ) rect( x: 20, y: 100, w: 25, h: 25, f: 'green' ) rect( x: 45, y: 125, w: 25, h: 25, f: 'green' ) }
All "shapes" have the save event handler, you are probably wondering if it is the same as the one showed previously here, which looks like
def dragMe = { e -> def point = e.event.point def shape = e.target shape.x = point.x - shape.width/2 shape.y = point.y - shape.height/2 }
But sadly it will only work for the rect node as the other two do not have a set of [x,y] properties (as a matter of fact an exception will be thrown), so what can we do to solve this? Luckily these operations support transformations so we may attach a translate transformation to them. Ok, but setting [x,y] is much simpler no? and surely it would be the same case if we could access the centre's coordinates of the star, right? Lastly, there is a gotcha using translate, how do we find out the correct offsets to set the relative [x,y] ?

Fear not because this is exactly what this post is about, all of these problems can be solved one at a time. All "displayable" operations (shapes, outlines, images and groups) share a common ancestor that provides a new set of methods useful in this situation Ok, those methods will help with the first two shapes (square and star), what about the group? let's look at the code and find out, shall we?
def dragMe = { e -> // e.event is the original MouseEvent def point = e.event.point def shape = e.target // the shape has been drawn already, // it is safe to query for its bounds def bounds = shape.bounds if( shape.hasCenter() ){ shape.cx = point.x shape.cy = point.y }else if( shape.hasXY() ){ shape.x = point.x - bounds.width/2 shape.y = point.y - bounds.height/2 }else{ // attempt a translate transformation if( !shape.txs['drag'] ){ shape.txs << translate( name: 'drag', x:point.x - bounds.x - bounds.width/2, y:point.y - bounds.y - bounds.height/2) // save bounds[x,y] in a custom properties map shape.props.anchor = [x:bounds.x,y:bounds.y] }else{ def anchor = shape.props.anchor shape.txs['drag'].x = point.x - anchor.x - bounds.width/2 shape.txs['drag'].y = point.y - anchor.y - bounds.height/2 } } }
The trick is storing the [x,y] coordinates of the shape's bounds the first time the event is processed, as they will be updated during the next repaint, making a mess if you use them as is. In order to solve this problem operations (and filters) now have a built-in extra set of properties (the props property in shape) that work pretty much as client properties do for Swing components, they are even observable too thanks to ObservableMap, so don't forget to register a PropertyChangeListener with props if you want to receive notifications when a key is updated. Note how named nodes are also used to query for a translation node, either to create a new one or update its settings.

Keep on Groovying!

graphics graphicsbuilder groovy

It all started when my good friend Alex suggested that nodes built with GraphicsBuilder should have a name property as Swing components do (I wonder what he may have in mind ) and it turned out to be a good idea, complementing the recent updates on event and render handlers.

As shown in a previous example, you may navigate a node's children using a ops property, which is actually a List, using array subscript notation, but with names now in place it is also possible to use a map-like notation to get a hold of a nested node. This feature has been extended to transformations, filters, paints and paths as well, so now you are able to get a reference to those nodes using either an index or a name.

Here is a list of the properties you may use in this way Assigning a name to a node doesn't create a variable reference, so it is not a replacement for the id attribute, it works in the same way as it does in SwingBuilder, where components may have a name (a regular property for JComponents) and a id property (a synthetic property used by the builder).

I expect to have the next release ready in the following days.

Keep on Groovying!

graphics graphicsbuilder groovy

If you have followed GraphicsBuilder's examples shown at this blog you have probably noticed that GraphicsBuilder has a lot of similarities with SwingBuilder, both create a hierarchical structure of nodes used to render artifacts to the screen, but GraphicsBuilder's operations are not rendered directly once built, it is the responsibility of a JComponent that understands these operations to call them in the context of a paint operation, as it is the case of GraphicsPanel. You can say that GraphicsBuilder has a design nature (the hierarchical structure of nodes) and the JComponent takes care of the runtime nature.

Because of these two natures you can't reach the graphics context while building (as it doesn't exist yet) and once you draw the artifacts on the screen is too late. This is the reason why every GraphicsOperation now has a pair of properties beforeRender/afterRender that take a closure as value, the runtime nature of the operations will assert that they are called at the proper time.

So now that we have access to the graphics context, what can we do with it? the following example shows a rectangle (presumably a background rectangle) that will always cover the full extent of the JComponent as it keeps in sync its width/height property with the JComponent's dimension
rect( w: 10, h: 10, f: 'white', bc: no, beforeRender: { context, op -> op.width = context.component.bounds.width op.height = context.component.bounds.height }, mousePressed: {e-> e.target.fill = 'red' }, mouseReleased: {e-> e.target.fill = 'blue'} )
There is no ComponentListener registered to keep the sizes in sync (though you could register one inside beforeRender) so in order to see the effect, you can resize the painting panel and click on the rectangle, that will trigger a property change which in turn will trigger a repaint on the panel, drawing the rectangle with updated dimensions. It is worth noting that even though you can change an observable property that may affect the visuals of the operation using this new option, PropertyChangeEvents won't be triggered while the closures are executing, otherwise an infinite loop would happen.

Granted this is a cheesy way to have an operation react to its containing component, I'm looking at a better option to lazily bind this behavior in a simpler way and not using the existing bind() node (which is also an option but requires that the panel/component be created before the graphics operation).

Keep on Groovying!

graphics