Here are some Swing links that you might have missed during this week:

• Jasper Potts posted an update on the Nimbus development progress. The screenshot shows the support for the different component sizes (using the same client properties as the latest Aqua drop). As the comments point out, there are quite a few visual inconsistencies which will be hopefully addressed (small and mini scroll bars, inconsistent scaling of arrow icons across different controls, small and mini indeterminate progress bars and text field shadows are among these).
• The latest drop of Dolphin addresses bug 6438179, providing correct implementation of tray service availability on Unix platforms. Backport to Update N highly desired.
• Danno Ferrin kicks off the slew of Groovy-related items with his overview of new Swing features in Groovy 1.5.
• Andres Almiray is back with a few postings of his own. Starting with CSS support in Swing / Groovy applications, he provides a little more information (and a screenshot) on GraphicsPad, and finishes off with updates on builders for WingS and Jide.
• Geertjan Wielenga blogs about integrating a YouTube player inside NetBeans IDE. A sad tribute to the lack of open-source video playback components in Java (he is using the commercial WebRenderer library). This is still on top of my wishlist for 2008, and is still foolish to hope for.

If you ever needed an argument against using a visual UI designer that enforces any logic on the code it creates, here it is:

In JBuilder 2007 CodeGear/Borland has completely dropped GUI editing support for the jbinit() stuff. So anyone who needs to update their old code need to rewrite it from scratch (which is a major risk) or handcraft it.

By show of hands – who would have thought in 1997 2000 (when JBuilder pretty much ruled the Java IDE landscape) that this could happen? Are you sure that NetBeans will outlive all the code that is being created by it as we speak? And by the way, the only complete visual UI editor that doesn’t impose any logic on the code it edits and is able to parse out even the most complicated custom forms that i have thrown at it comes from Instantiations. Now if only they could reduce the memory footprint from 400MB to something a little bit more realistic…

Following my entries on platform-specific font policies for Mac and Gnome, one of Substance users stepped up and provided an implementation that makes all Substance-powered Swing application pick the correct font sizes when running under the KDE desktop.

Here is a screenshot of a test application running under KDE desktop with font size of 10 and DPI set to 96:

and here is the same application, running under 120DPI, using font size of 10 except for menus which are configured to use italic 8:

The current implementation can be found in the CVS repository and was contributed by Paranoid (many thanks). It parses a few configuration files to get the DPI and font settings, providing fallback values in case these can not be found. Give the latest 4.2dev drop a try and let us know if you’re having any problems on KDE desktop.

The threading rules in Swing are one of the main reasons for the perceived slowness of Java desktop applications (it remains to be seen whether JavaFX will address this issue for anything other than toy demo applications that have started appearing lately). This article by John Zukowski is an excellent overview of the threading rules in Swing since its inception, and how to write applications that do not break the thread safety.

All different EDT-related rules pretty much boil down to one simple thing – anything that affects pixels on the screen should be done on EDT. However, these rules are all concerned about the where and not the when. And the when is very important. Here is the rule all Swing applications should abide by:

Event listener logic that affects pixels on the screen should schedule its execution after the current event has been processed by all registered event listeners.

The reason for doing this is simple – your application listener is not the only one that is registered for that specific event type. You might think that it’s the only one – after all, you know your application code inside out. However, there is much more going on “under the hood”, and that depends on the look-and-feel you’re using.

The look-and-feel doesn’t have any magic way of tracking the application state. Since the UI delegates use the same event / listener mechanism to track changes to control models, they rightfully expect the application logic to not interfere with the component state while the current change is being processed.

A simple example – application logic registers an action listener on a button. The action listener logic changes the UI state of the application (transitions to the next screen of the wizard, for example) and hides this button. After this action listener is done, the next action listener is called. What does it see? Surprise surprise – the button is no longer in the same state as it was when it was actually pressed.

The solution is very simple – wrap your action listener logic in SwingUtilities.invokeLater. I know, it makes the code ugly. I know, it makes the code go so much to the right side of your editor that you start hating Swing and contemplate switching to VB. But it is simply the right thing to do. You wouldn’t want any other listener to do that to the event source component, so why are you doing it yourself?