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

• Nazmul Idris has created a tutorial on SwingX painters. The painters generated quite a lot of heated discussion and development about half a year ago, and there were passionate talks about restructuring the entire Swing painting pipeline around the painters. It seems that once the big plan was shot down by the Swing team (and quite rightfully so since that would result in breaking a lot of existing code), no effort has been done to search for alternative ways to introduce painters into the core Swing library. The active development of SwingX painters seems to have died pretty much after that.
• Mikhail Lapshin answers a question posted on Swing forum on how to create menus that pop up only on mouse click (and not on mouse over). While this might confuse a user (i’ve tried a few native Windows applications and they all pop up menus on mouse over), some applications can still find this technique very useful.
• Eugene Kuleshov posts a riddle on achieving the specific layout with SWT, AWT or Swing. The simple answer is – do not use titled borders and nested panels. This has been long considered a bad design decision that adds unnecessary noise to the form. Use white space, tabbing and separators to create visual groups.
• Jan Haderka continues working on various parts of SwingX, and this time he presents his improvements on BusyPainter and JXBusyLabel. The demo comes with a very useful option to play with the settings and then generate the matching code (copied to the clipboard). My only recommendation would be to drop some of the irrelevant features (such as trajectory shifts and dimensions) and look at some other ways to convey infinite progress (warning, high visual overload :) )
• Andres Almiray wraps up version 0.4.3 of GraphicsBuilder, showing its many new features (the multipaints example looks very good) and hints at the forthcoming support for SVG in version 0.4.4.

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

• Laird Nelson dives into intricacies of keyboard shortcuts, actions maps and focus state inheritance to show you how to make all dialogs and frames to be disposed on pressing the ESC key. Hopefully this will be one of many entries in this series, and the Bricks project will live long and prosper :)
• Angry Mongoose laments the lack of Swing best practices. It is indeed the unfortunate reality that Swing developers live in. The wealth of well-compiled, updated and comprehensive information available to the consumers of alternative desktop technologies (such as WPF or Flex / Flash / Apollo) is astounding, compared to what is produced by training / marketing / evangelizing departments behind Swing (if any).
• Chiral Software brings the power of of JBoss, JSF, iText and JFreeChart together, showing how to create PDFs with rendered Swing components. The first part lays the groundwork, and the second part shows how to create vector-based charts.
• Sergey Malenkov is working on enhancements to the core JColorChooser component, and is asking for the community to step up and weigh in on the design. Unfortunately, the actual designers do not read programmers’ blogs, so this is most probably a lost call. Hopefully, there are some professional designers working on the JavaFX design tool. If it’s designed by the programmers, the end result will not move the designers away from the competing tools.
• Tim Dalton continues his explorations with Scala, using Swing as the “native” UI toolkit. This time, he takes a look at the newly announced Scene Graph library. While the first example shows just a few shapes and a translucent button, the second one is a little more interesting. Building on his previous example, he shows a rotatable calculator. It would be extremely interesting to know whether the rotated Swing controls continue responding correctly to the mouse events, something that Alex has had quite a few problems with.
• Andres Almiray continues beefing up the Groovy bindings for Swing, adding more capabilities to the GraphicsBuilder (here, here and here), and showing a nice example of the Linux penguin mascot done in Groovy.

One of the rules of good UI design is to use consistent coloring guidelines. One of the many reasons is the accessibility for color-blind users who might not be able to distinguish between light red and light green background for validation indications (reported seven percents of male population of United States can’t distinguish between green and red or see them differently). However, some applications can benefit from using colors to visually distinguish between controls, and one of the users of Substance look-and-feel has recently filed an enhancement to provide support for control colorization (attaching this screenshot as sample of the required UI).

And so, i’ve spent the better portion of the last two weeks on colorization support for the core Swing components. What started out to be an innocent and simple enhancement request turned out to be an excellent opportunity to revisit pretty much the entire Substance codebase, fixing few stray bugs and refactoring some duplicate functionality. This entry shows sample screenshots of colorizing awide variety of core Swing components, with support for SwingX and Flamingo component suites coming in the next release. If you want to play with live demo, click the button below, wait for the application to load, switch to “Colorized” tab, check the “colorize” checkbox and play with the slider (which sets the colorization amount).

And now let’s see some screenshots. Here is a collection of toggle buttons, checkboxes and radio buttons in different states (default, selected, disabled and disabled selected) under Business Black Steel skin:

Now, let’s set the background and foreground colors to some application-specific values and see how these controls look under Metal:

While some states respect the settings (for both background and foreground colors), others don’t. For example, the foreground for disabled is always light gray, the background for selected toggle buttons is always light gray. In addition, the checkmarks for check boxes and radio buttons respect neither custom background nor custom foreground. Let’s try under Windows look-and-feel:

This looks even worse than Metal and much of it is due to the limitations of native look-and-feels as described in this earlier entry. The buttons would be better off ignoring the custom settings at all – disabled foreground text is the same as enabled one, and the background is painted as a rectangular “ghost” border around the buttons.

While Substance hasn’t been much better up until now, the things look different in the latest 4.2dev build. Here are the same controls with 50% colorization:

As you can see, the colors of the original theme are now colorized with the custom background and foreground. The disabled controls still look disabled (colorization is not as strong), and the check marks of radio buttons and check boxes are colorized with the custom foreground colors. In addition, the background of check boxes and radio buttons is not colorized at all. Last but not least, the colorization implementation tries to preserve the brightness levels of the original colors, which results in consistent gradients even for large colorization values.

Let’s see how the same controls look under 25% colorization:

If the application requires more colorization, it can set it to anywhere between 0% and 100%. Here are the same controls under 75% (note that the gradients are still discernible):

Let’s see some other controls being colorized. Here are a few text components:

And a scroll pane with yellow background (propagating to the horizontal scroll bar) and green background on the vertical scroll bar (i still haven’t decided whether the corner should be colorized as well):

What about something a little more complicated such as table? The first row has enabled tables with green and dark green backgrounds, while the second row has the same tables disabled. Note how the background colorization is applied not only to the cells and header cells, but also to the table grid lines:

Another complicated example is a tree. Here, the colorization is applied to the striping, the cells, the tree lines and the tree collapse / expand icons:

Another complicated one is an internal frame. Here is a screenshot of desktop pane with custom blue background with four internal frames, two of them minimized. Note how the custom background of an internal frame is applied to its title pane, the title pane buttons, the frame border and the menu bar (first two apply for the desktop icons as well):

Going back to simpler controls, let’s see some sliders and progress bars:

and compare it with Metal:

The last screenshot shows the colorization of menu items (note how it applies to the text, check marks and the arrow icons):

I’d like to thank Luke Sleeman for creating this enhancement request and providing feedback on the initial implementation. To try it out, run the demo linked above. You can download the latest binaries and sources right here and play with the new SubstanceLookAndFeel.COLORIZATION_FACTOR client property which can be set on UIManager (globally) or on any component (applied to the component and all its children). The value should be a Double in 0.0-1.0 range. All the Substance screenshots in this entry have been taken under JDK 6.0 on Vista, with the Bramble plugin providing native text rendering.

These two features (native text rendering and colorization support) mark the code freeze for new core features in the next Substance release (code-named Memphis). At this point, they have resulted in only 40KB increase in the size of the binary library. The release candidate is scheduled for January 21st, with the release scheduled for February 4th.

I’ve already mentioned that the upcoming Nimbus look-and-feel is not being hosted in a usual location (javax.swing package). While at first the NimbusLookAndFeel class was in a sun.swing.plaf.nimbus package, it has now been moved to a new home – com.sun.java.swing.plaf.nimbus, whose parent package also hosts GTK, Motif and Windows look-and-feels.

Bug 6616742 is the reason – Nimbus was not available in unsigned applets due to class loading restrictions on internal sun.swing packages. It also fixes 6618285 – using the NimbusLookAndFeel class directly in the source code.