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

• Probably the biggest news of the week come from the latest b12 drop of JDK 6.0 update 10. As reported earlier, it provides support for native text rasterization on Windows, as well as translucent and shaped windows. This thread from java.net forums has more information on the native text rasterization, and the earlier blog entry describes the APIs to create translucent and shaped windows. Don’t skip the comments section that has quite a lot of additional information on performance and pixel-level translucency (for soft clipping shaped windows, for example).
• While these two features are in the latest development builds of 6u10, a lot of applications can benefit from this functionality in JDK 5.0. The native text rasterization is available under Substance look-and-feel and its Bramble plugin (using SWT), and Christophe writes about using JNA for pixel-level translucent windows.
• Jan Haderka writes about the latest stable 0.9.2 release of SwingX component suite library. The SwingX team has been very active lately, fixing a lot of bugs and providing very swift and professional response to user queries. Hope it won’t take too long before the official 1.0 release (JavaOne anyone? :) )
• On a related subject, Thierry Lefort continues to explore the SwingX components. His latest entry shows how to combine the JXTipOfTheDay component with Rome RSS parser to display an RSS feed as a tip of the day.
• As a “challenge” from one of Thierry’s earlier entries, Jeanette Winzenburg (the mastermind behind quite a few SwingX components) explores the renderer and highlight capabilities of the JXTable component.
• Patrick Gotthardt has announced the official 1.1 release of the Pgs look-and-feel.
• David Qiao of JIDE has announced the 2.2.2 release of JIDE components. I really wish that they had time to maintain an active blog to showcase the new features as they are made available. While the latest entry on rotating icons is quite useful, the previous “real” one was back in December. And on a related note, David will hold a birds of feather session at this year’s JavaOne. The topic is “Workaround Swing bugs” and he is looking for feedback on the bugs you would like to be discussed.
• Andres Almiray continues making the graphics development easier for Groovy heads. This week he takes a stab at balloon shapes, multiline text and text alignment.

Since this article was written in 2008, all the functionality discussed below has been exposed as officially supported public APIs. See the conversion table at the end of this documentation page for full information.

I first spotted it about a month ago, and today’s build 12 of JDK 6.0u10 delivers on the promise – translucent and shaped windows with core Java classes only!

So, what do you do? First, head over to the JDK6 space at java.net and install 6u10 build 12. After that, you need to point to that install from your project (either IDE or a build script). As Richard mentioned in his Javaposse’s spot, Sun couldn’t publish the relevant APIs in a java.* or javax.* package since officially 6u10 is still not considered a major release. So, the APIs are in com.sun.awt.AWTUtilities. Of course, this may change its place (like Nimbus did), but you can at least start exploring it.

There are a few public static methods in this class, and since the signatures are self-explanatory, you don’t really need the source code. For starters, the inner Translucency enum has three values:

• PERPIXEL_TRANSPARENT – ability to create a shaped window
• TRANSLUCENT – ability to create a translucent window
• PERPIXEL_TRANSLUCENT – ability to create a translucent shaped window

To test support for a specific translucency mode, use AWTUtilities.isTranslucencySupported(Translucency) API. To test whether the specific GraphicsConfiguration supports translucency, use AWTUtilities.isTranslucencyCapable(GraphicsConfiguration) API. This Java class is a simple test utility that illustrates the usage of these two methods. Best thing – even on my Windows 2003 server machine these APIs return true!

Once you know that a specific translucency mode is supported, it’s time to create a shaped and / or translucent window. Let’s start with a simple frame with a few controls (Simple window – java class). Here is how it looks like, with a button, a check box, a radio button and a progress bar:

Let’s make it shaped (Shaped window – java class). For this, we use AWTUtilities.setWindowShape(Window, Shape). It’s hard to say without seeing the code, but the window has to be undecorated – call JFrame.setDefaultLookAndFeelDecorated(true). Otherwise the window is shown in usual rectangular shape. It would be nice to have a boolean return value that indicates a success of the operation. Here is how our window looks now:

Let’s make a translucent window (Translucent window – Java class). For this, we use AWTUtilities.setWindowOpacityWindow, float). As you can see, the translucency factor is global, and (at least for now) you can not control translucency of each pixel. Here is how our window looks like with 50% opacity:

And you can combine both calls to have a translucent and shaped window (Translucent shaped window – Java class):

There are a few other additional public methods in AWTUtilities:

• getWindowOpacity(Window)
• getWindowShape(Window)
• setWindowOpaque(Window, boolean)
• isWindowOpaque(Window)

I think that the only two things that i’m missing is the per-pixel translucency support and soft-clipping of shaped windows (this would depend on the first item).

Congratulations to the AWT team for making this happen!

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

• Daniel Spiewak walks through the steps of creating a simple form, from sketching the design on a piece of paper to implementing it in code. Personally, i felt that the recommendation to select the layout that the specific developer feels comfortable with is not very good for long-term maintainability, and the team would be much better off with a solid and well-known third-party layout manager such as FormLayout. Not to mention that the resolution independence is a very important topic which should not be dismissed lightly.
• Wim Deblauwe writes about the intricacies of providing responsive UIs with SwingWorker, using a very basic and common scenario of wiring a progress listener to a long background task.
• On a related subject, Carl from Palantir dives into the SwingUtilities.invokeAndWait and its behavior in thread interruption scenarios.
• Thierry Lefort continues his explorations of table-based data visualisation techniques, using the JXTable component from SwingX component suite to provide filtering and highlighting capabilities. The second part uses a color utilities class to provide distinctive highlighting on selected cells.
• Tim Dalton posts an update on the progress of his SQUIB project that provides Scala bindings for Swing components. Reading the code examples on his efforts in Scala and the parallel efforts in Groovy i can’t help but think it is still not much more than syntactic sugar. Indeed, you save a few constructs here and there (which is not necessarily a good thing, at least in the short run). I’m not really sure what am i expecting, but i’m definitely lacking a “wow” factor, so to speak. Something that would make me want to switch to Groovy or Scala for my hobby dabblings in UI technologies.
• Jan Erik Paulsen has a teaser on the new application that he is working on in Teppefall Labs. Called Teppefall Capture, it allows capturing pictures and videos from an attached (web) camera. He rightfully mentions the abysmal state of affairs with respect to anything remotely related to video, and hopefully this situation will be addressed this year. My number one Java desktop wish for 2008 – where art thou?
• Chet Haase has announced that he left the Swing-land to work on Flex SDK. Personally, i wish him nothing but the best, and hope that he will have the same level of passion once the initial excitement over the new technology wears out.

About three months ago i wrote an overview of painters in Substance look-and-feel. Painters are one of the major building blocks of Substance, and over the last few releases they have been used extensively to provide consistent appearance to both core and third-party components. Unfortunately, the original painter design and responsibilities have not always stood the test of time, and one of the painters has grown significantly beyond its API. This has made the code more complicated, cryptic and in some cases, a pain to maintain. It applied not only to the internal code, but also to the external painter users (as outlined in the skinner primer).

Specifically, i am talking about title / header painters. Originally, the title painters were responsible for painting title panes of top-level windows (frames, dialogs), internal frames and desktop icons. Over the last few releases, they have evolved significantly to allow custom painting of other UI areas, such as menu bars, tool bars, task pane containers, status bars and others. As additional capabilities were added to the title painter API and implementation classes, it became clear that these no longer reflect the true usage – decoration painting. To this end, let me first introduce the new concept in Substance – decoration area type:

The <font color="darkblue">org.jvnet.substance.painter.decoration.DecorationAreaType </font>enum provides enumeration of available decoration area types. As a picture is worth a thousand words, the following screenshots illustrate the different decoration area types.

The following screenshot is the main Substance test application under the Business Black Steel skin (click to see full size version):

The next screenshot shows the title decoration area, which in this example includes the title pane of the main window:

The next screenshot shows the header decoration area, which in this example includes the menu bar of the main window:

The next screenshot shows the toolbar decoration area, which in this example includes the tool bar of the main window:

The next screenshot shows the general decoration area, which in this example includes the task pane container and status bar components from the SwingX suite:

Let’s go back to the original screenshot:

It illustrates that the specific skin assigns different color schemes to different decoration areas. The controls in those areas get the background and foreground colors based on their assigned color scheme (without any custom application code), thus creating visual distinction between different application areas.

In addition to the decoration painter, the latest development drop of version 4.3 (code-named Nairobi) introduces the new highlight painter API. The highlight painter is used to paint rollover and selection highlights on tables, trees, lists and menu items. In addition, it is used to paint highlights on third-party components, such as task pane container and month view in the SwingX suite.

For more information, please consult the following documentation:

• [new] Decoration painters
• [new] Highlight painters
• [updated] Skinning primer

If you switch to the latest 4.3dev binary drops, you might experience a few minor visual glitches. These will be addressed during the development cycle, but don’t hesitate to drop a mail or post a forum message if you find a regression. Also, if you were using the old title / header painter APIs or were providing a custom title / header painter in your application – first, apologies for breaking the binary compatibility, and second, i am here to help migrating your old code to the new painters.