Core Swing is in the process of being retired as a legacy UI technology inside Sun, and last week has marked another sad (yet expected) milestone. According to Jeanette Winzenburg‘s post on the SwingLabs java.net forum, Sun has stopped funding of the SwingX project.

Announced at JavaOne 2004 under the JDNC brand, SwingLabs has been widely considered as a breeding ground for modern UI technologies (new components, markup language, binding etc) for later inclusion in the core JDK distribution. It has enjoyed significant attention from the Swing community, drawing dozens of outside developers to contribute code and discuss various approaches to provide modern, rich and customizable components. Perhaps the culmination of these discussions happened in 2006 around the painters. The community members (IMHO) have truly believed that SwingX is being officially regarded inside Sun as a gateway for those contributions to find their way into the core Swing, and the level of excitement was clearly visible throughout the well argumented and heated discussions about the painters.

In my view, the turning point has come in January 2007 when it was announced that Sun unilaterally has decided to remove the entire painter layer from SwingX. This has effectively destroyed the trust of external contributors, who never came back, even after Sun developers have retired themselves from being involved in the project. In this light, Amy’s comment on Jeanette’s thread is a little misguided:

SwingLabs isn’t being shut down and SwingX isn’t going anywhere — it’s a great extensions library that exists because the community drove the development in the direction they needed. I don’t see that ending.

In fact, that single internal decision that completely disregarded the whole year of discussions was the most unfortunate moment in the project’s history. Looking back, it is even more unfortunate since SwingX components are not going to be part of core Swing (more on this later). Up until that moment the community has believed that it had an equal say in the development direction. After that moment most of the community has left, and a few months later Sun has decided on the new direction – JavaFX.

I don’t know what the future holds for JavaFX. Sun is heavily betting on it, and nobody wants to have their Nomad moment forever archived on the Internet. All i know is that JavaFX has effectively halted all core Swing development. Over the last 18 months, we have seen significant architectural initiatives (JSR 295 and JSR 296) changing leads and frozen. All client-facing improvements in Java2D, AWT and Swing in Java 6 Update 10 are completely driven by the requirements of JavaFX. In Richard’s own words (the same thread on SwingX funding):

Swing is part of the JDK. It isn’t going away any time soon. For a great many large enterprise applications Swing is the best cross platform toolkit available. We’ll continue to support and work on fixing bugs in the JDK.

It can’t get any clearer – the only two active areas of Swing core work is support and bug fixing. You might say that things will change once JavaFX 1.0 is out the door, but this is quite unlikely. JavaFX has a lot of ground to cover if it is to compete with Adobe and Microsoft, and it has even more ambitious plans for mobile and set top environments. In Richard’s words:

Definitely no question that there is a lot of working going into JavaFX and will continue to happen.

What do i see happening? I think that the current core Swing feature set should be considered frozen, until shown otherwise (not in words, but in actions). Swing is an extremely well written and customizable UI toolkit, and it is a solid candidate when you consider writing your next UI application. However, the innovation must come from third-party developers, be it binding, application framework, components or markup language. As the Swing Links trail on this blog shows, there is a lot of external activity in this area.

I think that core Swing has become a victim to Sun’s outdatedly rigid policy on the backwards compatibility. I have written about this topic in the Substance users mailing list a few weeks ago:

The eternal fear of Java core libraries is to never break existing applications (by the way, the Swing forums are rife with examples of applications that break when migrated to a newer JDK versions; it doesn’t have to be EDT violations, something as simple as event firing condition due to a bug fix is enough). This fear has us stuck with Ocean as the default look-and-feel. This fear has us stuck with tons of deprecated APIs that unnecessarily complicate the learning curve for the novice users (how many ways to catch an Enter key on text field?) This fear has us stuck with obsolete layout managers (gridbag, spring). And by the way, this fear also prevents the core developers from adding new functionality out of the fear itself that they might get it wrong the first time and get stuck with it forever.

Like i said before, in the grand scheme of things, it all doesn’t matter. Technologies die, new technologies are born, people move to other companies, old prejudices refuse to die and some decisions are forced on technical people. The customers, of course, couldn’t care less about all this.

About two months ago i have discontinued my support for the Substance NetBeans module. Today, i am happy to report that John C. Turnbull (who was, in fact, the first to comment on that announcement) has agreed to take over the ownership of this project.

John is now the official owner of the project, and all decisions regarding this project will be at his sole discretion. The core Substance library (and other plugins) will continue to be developed by me, and John will have my full cooperation on evolving the external and internal APIs to facilitate the ongoing development of Substance NetBeans module (the decisions regarding the core library will still be made by myself).

If you wish to contribute to this project, you’re welcome to drop John a line on the mailing lists of forums. You can also read John’s announcement on the NetBeans user list.

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

• Fabrizio Giudici writes about an embedded screencast recorder for Swing application written by Jeremy Wood. It has a custom repaint manager that tracks dirty rectangles, and global event handlers to track mouse and component events.
• Jeremy Wood himself blogs about customizable toolbars that support drag-and-drop reordering of the items.
• Matt Nathan has created the first draft of documentation on scalable icons. He starts off by surveying the three different design options that he considered, and then delves deeper into his ScalableIcon interface, showing how to implement and use it.
• Mirko Stocker writes about Java UI testing with JRuby, comparing SWTBot and Marathon tools.
• Ken Orr has a tip to use look-and-feel consistent fonts onthe JEditorPane component. A fortunate coincidence had Ken posting this just a few hours after this question has been asked on the Substance forums :)
• Henry Lander has announced release 2 of the Java Print Dialog Framework.
• Bernhard Huber writes about integrating Groovy SwingBuilder and the XHtmlRenderer (Flying Saucer) project.
• The latest feature article on java.net by Joshua A. Davis and Thaddeus Keenan Simmons shows how to integrate OpenGL and Java2D.
• Jean Francois Poilpret is getting ready to release version 1.0 of DesignGridLayout in a few days, and he has created a five-part series (part 1, part 2, part 3, part 4, part 5) that follows the development takeover of the project.
• Don DeCoteau was interviewed last week on this site, and he follows up with version 0.9.1 of Sage engine. Noteable additions include map viewer and coverflow viewer available in a standalone jar.
• Alex Ruiz writes about respecting the EDT rules in the FEST-Swing library. It is great to see this topic getting the attention it deserves, because even veteran Swing developers still have serious misconceptions about EDT rules in particular, and multi-threading issues in general.
• Christophe Le Besnerais shows how to use the JXLayer library to highlight search results in an Explorer clone demo. JXLayer is written by Alexander Potochkin and it is one of my favourite third-party Swing utilities.
• Mikael Grev has started writing the media player, and has hit a serious performance issue with translucent windows in 6u10 under Windows. In the followup comments he hints at finding a solution, so perhaps not all is lost yet…
• Finally, those living around the Bay Area are welcome to attend the free Silicon Valley Code Camp community event. It is going to take place on November 8-9 (this Saturday and Sunday), and among the 116 sessions you can find Alex Ruiz talking about UI testing, Andres Almiray talking about Java2D / Groovy and Groovy SwingBuilder.

All in all, this week has seen more Swing blogosphere activity than JavaFX has seen over the entire last month :)

The latest addition in the Flamingo component suite is support for rich tooltips on command buttons. This has been one of the items on the roadmap for version 4.0 (code named Fainnear), and is now available in the latest 4.0dev drop of Flamingo core and 5.1dev drop of Substance Flamingo plugin.

The org.jvnet.flamingo.common.RichTooltip class provides the API to define different parts of the rich tooltip:

• Title text
• Optional main image
• One or more description paragraphs
• Optional footer image
• Optional one of more footer paragraphs

To set the rich tooltip on the command buttons, use the following APIs:

• org.jvnet.flamingo.common.AbstractCommandButton.setActionRichTooltip to set the rich tooltip on the action area of a command button.
• org.jvnet.flamingo.common.JCommandButton.setPopupRichTooltip to set the rich tooltip on the popup area of a command button (does not apply to toggle command buttons in the JToggleCommandButton class that only has an action area).

In addition, you can set the rich tooltip on the ribbon application menu button with the org.jvnet.flamingo.ribbon.JRibbon.setApplicationMenuRichTooltip API.

Unlike the core Swing tooltips, there are rigid rules that define the location of the rich tooltips. The rich tooltips will appear directly below the associated command button, left aligned with it. Here is a screenshot of an action rich tooltip under Metal:

And here is the popup rich tooltip of the same button:

As you can see, the rich tooltip provides support for multi-paragraph sections with optional images.

When a command button is part of a ribbon band, its rich tooltips will be shown below the ribbon. Here is a rich tooltip of action area of the Paste button in the first ribbon band (note how the tooltip is displayed below the ribbon and does not hide any part of the ribbon):

The left horizontal alignment makes sure that the tooltip is clearly associated with the command button (since there is a considerable vertical space between them). The same command button has a different rich tooltip for the popup area:

As mentioned earlier, you can associate a rich tooltip with the application menu button:

Command buttons in the application task bar show the rich tooltip directly below:

The previous four screenshots were taken under the Windows look-and-feel in Vista. Since one of the most important goals of Flamingo is to support other core and third-party look-and-feels out of the box, the rich tooltips are not an exception. The customization hooks provide complete control over the layout and appearance of the rich tooltips (and these will be illustrated below for Substance), but the rich tooltips should look consistent even without any customizations.

Here is the rich tooltip under Nimbus:

Here is the rich tooltip under Looks PlasticXP (note how it takes the translucent shadow border):

And the rich tooltip of the application menu button:

The rich tooltip under Synthetica Blue Steel:

And under A03 (for the application menu button):

Finally, third-party look-and-feels can customize the appearance of the rich tooltips. Both the layout and the painting itself is customizable via the usual look-and-feel hooks (on the UI delegates), and Substance Flamingo plugin takes an advantage to provide custom gradient fill.

Here is the rich tooltip under the Substance Blue Steel (on the Cut button):

And the rich tooltip on the application menu button under the Substance Autumn:

To see the rich tooltips in action, click the WebStart launch button below:

In this test application the rich tooltips are installed on:

• the application menu button
• the Paste button in the Clipboard band
• the Cut button in the Clipboard band
• the Paste button in the application taskbar
• the Bold, Italic, Underline and Strikethrough buttons in the Font band

As always, you are more than welcome to leave comments and report bugs on the project issue tracker, mailing lists or forums.