Since FEST allows you to alter the properties of the widgets directly, I didn’t have to do anything special to trigger actions on the JXColorSelectionButton. At first look, I thought that specifying mouse click point locations would be necessary, but after digging a(very little) bit I discoveregroovyd that FEST exposes the underlying Component its’ Fixture classes wrap as an internal ‘target’. Simply grabbing that Component and settings the background color directly was sufficient.
Here is the new definition of the JXBusyLabel and the 3 buttons which controls its color changes. You can see that two of the three color changes happen automagically due to Groovy binding – setting the background color of the label didn’t appear to work for some reason that I have yet to puzzle out, so it gets a PropertyChangeListener ‘old school style’.

baseColBtn = colorButton(name: 'baseColBtn', background: model.baseColor)
highColBtn = colorButton(name: 'highColBtn', background: model.busyColor)
backColBtn = colorButton(name: 'backColBtn', background: PaintUtils.BLUE_EXPERIENCE.getColor1())
backColBtn.addPropertyChangeListener("background", {PropertyChangeEvent evt ->
      label.setBackground((Color) evt.getNewValue())
      label.setOpaque(true)
} as PropertyChangeListener)

label = jxbusyLabel(name: 'busyLabel',
      preferredSize: new Dimension(model.W / 2 as int, model.H / 2 as int),
      busyPainter: busyPainter(
      highlightColor: bind { highColBtn.background }, baseColor: bind {baseColBtn.background},
      points: bind {slider.value}, trailLength: bind {tSlider.value}),
      opaque: false,
      horizontalAlignment: JLabel.CENTER,
      delay: bind {speedSlider.value},
      background: bind{backColBtn.background})

The three associated tests are essentially using the same recipe, so here’s just one of them to give you the idea.

 /**
 * Test that changing the 'baseColBtn' background color simultaneously
 * changes the busy label's base color.
 */
 @Test void testBaseColorChange() {
       startAnimation()
       def button = window.button('baseColBtn')
       def busyLabel = findBusyLabel()
       Color start = button.target.background
       Color busyStart = busyLabel.busyPainter.baseColor
       Assert.assertEquals(busyStart, start)

       button.target.background = Color.RED

       Assert.assertFalse(button.target.background == start)
       Assert.assertFalse(busyLabel.busyPainter.baseColor == busyStart)
       Assert.assertEquals(busyLabel.busyPainter.baseColor, Color.RED)
 }

Running the test suite takes less than a minute, and most of that time is spend dragging sliders. Those tests are presently going through the entire range of the slider, which is reassuring when actually watching the tests run, but probably overkill in terms of testing. Considering that, running the test suite is pretty painless and quick(the new tests execute in < 1s for instance). And of course the test results are available in the standard, pleasing, and hopefully all green, TestNG output. Which has, by the way, just announced another release thanks very much to its creator Cedric Beust.

I am still having some difficulties in responding to change events on the other sliders in the demo, but I think that I just need to decompose the parts into the MVC structure a little more coherently. In particular, when some sliders are moved, it should trigger some calculations and a repaint of the busy label to reflect the changes(not simple properties that can utilize binding directly). While the original code declares the method inline, I’ve moved it to the controller class and run into some circular dependency problems between the components referenced therein – Component A needs Component B but it hasn’t been instantiated yet in the view, etc. It looks like what is happening is that the change listener is being triggered once when it is assigned to the component, which might be a problem anywhere in Swing/Groovy/Griffon/my implementation. My money is on my own impl, mostly based on the common sense that when you’re writing code in an unfamiliar area you’re bound to meet problems that don’t immediately suggest a solution.

We’ll just have to keep digging and see.

[Show as slideshow]

[View with PicLens]

Related posts:

1. Griffon SwingX Fest testing
2. SwingX busy label demo in Griffon and Groovy
3. A One Day Griffon Application/Presentation

So the SwingX demo has 3 sliders that affect integer values on the JXBusyLabel. Using the Groovy ‘bind’ syntax, responding to changes in these events is simple to say the least.

And as promised in the last post, I’ve written some FEST tests to validate that everything is working as expected. Stay tuned to the end of the post to see a video of the running tests

FEST provides some convenience wrappers for UI elements that allows easy access to common operations. Looking up a JSlider in the UI for instance, returns a JSliderFixture object with a nice little ‘slideTo’ method.
First off, here are the UI components under test. Yes, this is the entire code, including all necessary wiring to trigger updates automagically as the sliders are changed.

speedSlider = slider(
        name: 'speedSlider',
        sliderModel: boundedRangeModel(
                min: 1, max: model.SPEED_MAX - 1, value: model.SPEED_MAX - 1, extent: 0),
        opaque: true)

slider = slider(
        name: 'slider',
        sliderModel: boundedRangeModel(
                min: 1, max: 50, value: 8, extent: 0), opaque: true)

tSlider = slider(
        name: 'tSlider',
        sliderModel: boundedRangeModel(
                min: 1, max: 20, value: 4, extent: 0), opaque: true)

label = jxbusyLabel(name: 'busyLabel',
        preferredSize: new Dimension(model.W / 2 as int, model.H / 2 as int),
        busyPainter: busyPainter(
                highlightColor: bind { model.busyColor }, baseColor: bind {model.baseColor},
                points: bind{slider.value}, trailLength: bind{tSlider.value}),
        opaque: false,
        horizontalAlignment: JLabel.CENTER,
        delay: bind{speedSlider.value})
........
buttons.addLine(button(name: model.START_NAME, action:startAction))

And then the tests run against them. Each test moves a slider sequentially from the minimum to the maximum values and checks at each change to ensure that the same change is reflected on the bound JXBusyLabel property. Because the JXBusyLabel does not have a ready corresponding FEST built in fixture class, we just look it up as a Component by inspecting the UI for the appropriate named Component. The Groovy dynamic type system makes accessing its internal properties trivial after that.

/**
   * Start the animation and then ensure that changing the speed slider changes the delay.
   */
   @Test void testSpeedSlider() {
     def button = window.button(JXBusyLabelDemoModel.START_NAME)
     button.click()
     def JSliderFixture slider = window.slider('speedSlider')
     ComponentFinder finder = BasicComponentFinder.finderWithCurrentAwtHierarchy();
     def busyLabel = finder.findByName(app.appFrames[0], 'busyLabel')
     Assert.assertNotNull(slider)
     Assert.assertNotNull(busyLabel)
     (1..JXBusyLabelDemoModel.SPEED_MAX - 1).each { speed ->
       slider.slideTo(speed)
       Assert.assertEquals(busyLabel.delay, speed)
     }
   }

  /**
   * Start the animation and then ensure that changing the points slider changes the
   * number of points.
   */
   @Test void testPointsSlider() {
     def button = window.button(JXBusyLabelDemoModel.START_NAME)
     button.click()
     def JSliderFixture slider = window.slider('slider')
     ComponentFinder finder = BasicComponentFinder.finderWithCurrentAwtHierarchy();
     def busyLabel = finder.findByName(app.appFrames[0], 'busyLabel')
     Assert.assertNotNull(slider)
     Assert.assertNotNull(busyLabel)
     (1..50).each { points ->
       slider.slideTo(points)
       Assert.assertEquals(busyLabel.busyPainter.points, points)
     }
   }

  /**
   * Start the animation and then ensure that changing the trail slider changes
   * the trailLength.
   */
   @Test void testTrailSlider() {
     def button = window.button(JXBusyLabelDemoModel.START_NAME)
     button.click()
     def JSliderFixture slider = window.slider('tSlider')
     ComponentFinder finder = BasicComponentFinder.finderWithCurrentAwtHierarchy();
     def busyLabel = finder.findByName(app.appFrames[0], 'busyLabel')
     Assert.assertNotNull(slider)
     Assert.assertNotNull(busyLabel)
     (1..20).each { trailLength ->
       slider.slideTo(trailLength)
       Assert.assertEquals(busyLabel.busyPainter.trailLength, trailLength)
     }
   }

It’s particular amusing to note that the test code is more verbose than the Swing component setup. Man, after all of the Swing code I’ve written, WHY WAS NONE OF IT EVER THIS EASY!
Sorry for the shouting, but it’s late and updating this code to use binding instead of change listeners AND writing the tests AND writing this blog post took all of about 45 minutes. So you’ll have to forgive me for getting excited and all.

Here is the promised video showing the FEST test suite being run.. Give it a second as the first round of tests(not shown in the code above) do a bunch of assertions to make sure that all of the expected Components can be found. Not terribly interesting to watch, but a great win for Java GUI testing!

Related posts:

1. More Groovy/Griffon/FEST Testing
2. SwingX busy label demo in Griffon and Groovy
3. SwingSet on Griffon

The SwingX demonstration makes use of an inner ‘DetailsPane’ class that nicely handles a lot of the gridbag layout details, but I didn’t really want to spend the extra time Groovifying a perfectly good and already implemented helper class, so I just threw the java code in the Griffon src directory and that was that. Being able to seamlessly mix Java and Groovy is a definite plus, let me tell you. Below is an example of adding a new DetailsPane using the builder DSL, utilizing a GridBagConstants variable named ‘gbc’ and assigning the foreground color based on a model property.

genPane = jxpanel(constraints: gbc,
                              new DetailsPane("General settings:", model.FOREGROUND))

Here is a side-by-side comparison of Java and then the equivalent Groovy code for creating and initializing a new JXBusyLabel. At first they don’t look a whole lot different, but if you notice, the Groovy version is actually a one-liner, and uses the bind() syntax to set colors based on a model backed property.

 label = new JXBusyLabel(new Dimension((int) (W / 2), (int) (H / 2)));
 label.getBusyPainter().setHighlightColor( new Color(44, 61, 146).darker());
 label.getBusyPainter() .setBaseColor(new Color(168, 204, 241).brighter());
 label.setOpaque(false);
 label.setHorizontalAlignment(JLabel.CENTER);

label = jxbusyLabel(
       preferredSize: new Dimension(model.W / 2 as int,model.H / 2 as int),
       busyPainter: busyPainter(highlightColor: bind{ model.busyColor },
       baseColor: bind{model.baseColor}), opaque: false, horizontalAlignment: JLabel.CENTER)

SwingX contains a specialized button that wraps a color chooser component, and here we can look at the differences between the Java and Groovy syntax for instantiating one. The JXColorSelectionButton class isn’t actually a node made available by the SwingXBuilder, but adding to the builder syntax dynamically is simple to say the least using a call to ‘registerBeanFactory’. Also in the Groovy version, here we’re not directly updating the color on the label, we’re updating the model. While the background color change seems to be correctly updated through the bound ‘baseColor’ model property, it does not repaint automagically. I’m sure there’s a way to do this, it just hasn’t popped up yet.

JXColorSelectionButton baseColBtn = new JXColorSelectionButton();
baseColBtn.setBackground(label.getBusyPainter().getBaseColor());
baseColBtn.addPropertyChangeListener("background", new PropertyChangeListener() {
      public void propertyChange(PropertyChangeEvent evt) {
           label.getBusyPainter().setBaseColor((Color) evt.getNewValue());
           label.repaint();
      }});

registerBeanFactory('colorButton', JXColorSelectionButton.class)
baseColBtn = colorButton(background: model.baseColor)
baseColBtn.addPropertyChangeListener("background",
      {PropertyChangeEvent evt ->
           model.baseColor = (Color) evt.getNewValue()
           label.repaint()     //need to figure out how to remove this call!!!
      } as PropertyChangeListener)

The Java code uses an anonymous inner class to kick off the process.

new JButton(new AbstractAction("Start") {
      public void actionPerformed(ActionEvent e) {
           label.setBusy(!label.isBusy());
           putValue(Action.NAME, label.isBusy() ? "Stop" : "Start");
      }
 })

No anonymous inner classes in Groovy, and with the Griffon framework we can separate the concerns a bit better anyhow. This code is split up between the view and the controller classes. Note that the controller can reference(and update) the action by acting through its injected view component.

/* action and button defined in the view */
actions {
      action(id: "startAction",
      name: model.START_NAME,
      mnemonic: "S",
      accelerator: shortcut("S"),
      closure: controller.start)
 }
button(startAction)
...
/* controller action */
def start =  { ActionEvent evt ->
      view.label.setBusy(!view.label.isBusy())
      view.startAction.putValue(Action.NAME, view.label.isBusy() ? "Stop" : "Start")
 }

Finally, here’s a code sample of how to add a listener to an existing component and bind the action to a method on the controller:

     xSlider.addChangeListener(controller.&fcl as ChangeListener)

In most cases, the sample code here is not trying very hard to shorten the syntax; there’s a lot of room for improvement and further Groovification. I’m sure there’s a better way to add listeners, for instance. Anyhow, aside from a few details, the application is up and running and doing the same thing as the original. Total effort expended: probably about 10 hours, a good portion of it spend Googling and reading. Next step is to write some tests to get better at that side of the equation. I’d be including more links about the excellent SwingX components in this post, but the SwingLabs website has been reporting “Maximum Connections Reached: 4096 — Retry later” all day. Hope everything gets fixed soon guys!

If you’re interested in seeing this demo live and in action, there’s a link to a short Jing video below.

Click here for video of the JXBusyLabel demo running on Griffon.

Related posts:

1. More Groovy/Griffon/FEST Testing
2. Griffon SwingX Fest testing
3. SwingSet on Griffon