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

• hasCenter() - returns true if the operation has [cx,cy] properties
• hasXY() - returns true if the operation has [x,y] properties
• bounds - returns the bounding rectangle, this value is calculated after the operation has been executed, so you can't access it with a beforeRender handler (it will be null).

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!