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!