The first volume of Substance sightings was published last August and featured four Swing media-oriented applications. The purpose of this series is to highlight the capabilities that Substance look-and-feel brings to Swing applications, and the second volume showcases three open-source audio players with Substance-powered UI.

The first audio player is aTunes (hosted on Sourceforge as well), and it takes advantage of a few Substance APIs. Here is a sample screenshot of aTunes under the dark Raven skin (click to see full-screen image):

And here is another aTunes screenshot under the Business Black Steel skin. Note that both screens use vertically rotated tabs (in the top left corner) and the status bar component from SwingX component suite rendered by the Substance SwingX plugin:

The final aTunes screenshot shows the UI under Arabic locale. Note how Substance handles the right-to-left orientation of title pane buttons, menus, sliders, table headers and tabs:

The second player is Jajuk (which is also hosted on Sourceforge). Here is a screenshot of Jajuk in action – note how it uses an image-based watermark:

Unlike aTunes, Jajuk uses a few custom components that are not painted by Substance (the title bars of inner docked views and some of the buttons).

The last one is Xtreme Media Player (also hosted on Sourceforge). Unlike aTunes and Jajuk, Xtreme MP uses a custom Substance skin to create a unique look for the application. Here is a screenshot of XtremeMP in action:

This application uses SwingX and the matching Substance SwingX plugin as well (for the status bar). In addition to a custom Substance skin, it also takes advantage of the Substance button shaper functionality, setting custom button shapers on the control panel buttons:

Once the application defines the contour of each button, Substance takes care of the rest, including mouse hit detection and proper animation sequences.

If you haven’t tried Substance in your application, you’re more than welcome to do so. The current stable release is 4.3, and the next 5.0 version is available in early development drops.

If i had to put a number on it, i would say that more than 90% of the feedback that i receive on my projects is on bad behavior (exceptions, visual artifacts, broken APIs etc). I don’t complain. Not only this person decided to download and evaluate one of my projects. He also decided to spend his time to report the problem he is seeing via the project forums, mailing lists or a private e-mail. I’ve said it before and i’ll say it again – a feature that has absolutely no feedback is a feature that nobody is using.

In fact, as a developer myself i don’t even expect the “thank you” e-mails (and this post is most certainly not a solicitation for one). However, i would like to use this space as a collective “thank you” to all the open-source libraries that i am using and the people behind them. Please know that when you don’t hear from me, it only means that your library is working as expected. Thanks for all your free time and countless hours spent working on your projects. Thanks for spending this time away from your other hobbies, and sometimes even away from your family. It is much appreciated by your users. It is much appreciated by the community in general, even when we decide to go with a competing solution. Having choice is good for us as users, but it is also good for you as developers.

I would also like to thank the developers of the core engine itself. The work that you do on the JDK is seen by millions of people and even when we complain, it is all in good spirit. Do not be discouraged when you make a great new feature and all people seem to focus on is one specific bug that is still unfixed in the core.  It is in our nature to exaggerate and focus on the negative, but this does not mean that we do not appreciate the work that you are doing.

And finally, i would like to thank developers working on new projects and exploring new frontiers. Keep up the work and don’t get discouraged by the level of attention from the outside community. Good ideas take some time to settle in and win developers’ hearts.

With release 4.3 of Substance look-and-feel available last Monday (and a few patch releases to address bugs since then), it is time to think about the next release. Substance is now three years old and it has seen fourteen releases since it was started in April of 2005. Most of the minor releases did not introduce binary incompatibilities, and the last two major releases (3.0 and 4.0) touched the public APIs in ways that should have affected only a small portion of users. However, due to my very heavy commitment to make Substance the library of choice to create modern user interfaces (and resulting short release cycles), sometimes i have made bad decisions on the features to include and the APIs to expose them.

Over the last year and a half the Substance codebase has become a complex thing to understand and maintain. Every new feature that has been added (especially the skins and decoration areas) made it ever more difficult to maintain backwards compatibility and still address the needs of designing modern UIs. This sometimes led to an awkward implementation and even more awkward public APIs (as anyone who dared to use a SubstanceComplexTheme would attest).

Even though i am the single developer on the project (but thanks to all those who sent bug fixes and graciously contributed portions of code), i found it increasingly harder to understand and extend existing functionality. And here i am not talking about working on the project every other weekend; i look at and work with the code pretty much every day. Something had to be done, and over the last eight months i have considered the two options that i had.

The first option would be to start a new project. Learn from all the mistakes that i’ve made, all the features that were added and not used, all the accidental complexities that grew exponentially and didn’t really mesh well together, all the nice-to-haves that added performance hit even when not used. In short, stop working on Substance (moving into maintenance bug-fix mode only) and start anew.

The second option would be to wait for the next major release and do all the things necessary for the long term health and viability of the project. To rework the cruft and the mess into an API that best reflects my understanding of creating modern UIs as i see it at this moment. To put myself into my users’ shoes and question every client property, VM flag and API method. To see how hard it is to customize the default behavior without reading the Javadocs and the documentation. To see how hard it is to create a custom skin after reading the source code of existing core skins. And most of all, to see what can be sacrificed in the short term to address the long-term problems.

The first drop of the next major release (code-named Substance 5) will be available for download tomorrow. Here is the list of major changes that have been made to the core library and its plugins.

• Requires JDK 6.0. The only VM that is being used for tests is 6u10.
• SubstanceLookAndFeel class is now abstract and does not have any public constructors. Use a core skin-based LAF, extend to set a custom skin or use static setSkin method.
• Removed support for pluggable text rasterizers (substance-bramble plugin based on SWT). 6u10 addresses poor Segoe UI rendering on Vista.
• Addressing performance. The first drop of 5.0 is 20% faster than release 4.3. This is work in progress.
• Reworked notion of themes. Split the functionality of SubstanceTheme, SubstanceComplexTheme and SubstanceSkin into SubstanceColorScheme, SubstanceColorSchemeBundle and SubstanceSkin. Tweaked most of the core skins to take advantage of the new more flexible and straighforward APIs.
• Removed most of the VM flags. The only two flags are for tracing memory allocation and heap status. Use skin / image watermark / configuration APIs.
• Reconciled APIs that were added to address specific user requests and did not result in a consistent API. This should make making a custom skin / tweaking default Substance behavior easier and more straightforward.
• New client property to provide per-window skinning. Can use different skins for different top-level windows.
• Removed the client properties and APIs for setting themes and painters on per-component level. Use colorization client property and per-window skins for custom tweaking.
• The new default mode does not add any extra UI elements (menu search, lock icons etc).
• Removed performance-adverse functionality of custom overlay and composites. Was unintentionally broken since release 4.2 and intentionally unfixed in both 4.2 and 4.3. A single complaint shows that this functionality is of minuscule use.
• Removed combobox auto-completion. Use SwingX, GlazedLists or JIDE.
• Moved UI debug mode (additional context menu on title panes and scroll bars) to a substance-tools plugin
• Consolidated existing theme pack, button shaper pack and watermark pack into substance-extras plugin
• New SubstanceApi annotation marks public APIs (classes, constructors, methods)
• Internal restructuring of the packages to make the codebase more organized.

Undoubtedly, the most important bullet in this list is moving to JDK 6.0 as the runtime requirement. This has not been a minor decision. I understand that for a great number of users this will mean that they will not upgrade to Substance 5. I am doing this for the long-term health of the project.

At this point, release 4.3 officially enters into the longterm bugfix mode. With older releases i only backported bug fixes during the first week after a stable release. Release 4.3 will continue to receive all but most complicated bug fixes to accommodate users that can not upgrade to Substance 5 (due to JDK requirements).

For more information on changes to the client properties, VM flags and APIs consult the first draft version of the API change overview document. The project documentation will be updated in the following weeks.

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

• Sandip Chitale has two tips on using JOptionPane component. The first tip show how to use multiline text and images, and the second tip is on making the component dialog resizable.
• David Qiao has announced the official release 2.0 of JIDE Desktop Application Framework.
• Maxim Zakharenkov has announced release 1.0 of the Swing Explorer project. The getting started guide shows the potential of this project for visual debugging of Swing application. The player feature looks particularly impressive.
• Nazmul Idris sums up the limitations of the current native font rasterizer in 6u10 latest builds.
• Geertjan Wielenga writes an overview article on FEST-Swing project by Alex Ruiz and Yvonne Price.
• Roman Kennke posts updates on the Caciocavallo project. The first is on build errors, and the second is on font rasterization.
• Fabien sums up a few libraries and tools that help building Swing applications.
• And finally, the Glimmer project proposal has been accepted by Eclipse. The goal of this project is to wrap SWT with a JRuby DSL for easier authoring of cross-platform user interfaces. While interesting on itself, this might also prove a good catalyst and inject some life into the Swing-based efforts in Groovy, JRuby and Scala.