Substance 4.2 official release

February 4th, 2008

It gives me great pleasure to announce the official release for version 4.2 of Substance look-and-feel (code-named Memphis). The list of new features includes:

In addition to the core release candidate, the following Substance plugins and modules have been updated as well:

A few screenshots of the new functionality in Substance 4.2:

Support for native text rasterization (viewed here with Segoe UI 12 pixel font under Windows Vista on JDK 5.0):

Component colorization with 50% factor (both background and foreground):

Respecting the KDE desktop font settings:

Better visuals for disabled controls under Raven Graphite skin:

Removing visual noise on tables and table headers in scroll panes:

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

  • Chris Campbell introduces Effects Framework, the third major component of Scene Graph project. Some of the effects seem to be based on Romain’s original work on new blending modes, and some look to bring Photoshop-based functionality to Java and JavaFX applications.
  • Speaking of the JavaFX focus in the upcoming 6.0 update N, there are two very interesting bug reports in the bug parade. 6656651 talks about native font rasterizing (at least on Windows platform) and 6655001 hints on support for translucent and arbitrarily shaped top-level windows, backed up by hardware acceleration on Windows Vista.
  • The Groovy community continues charging ahead with wrapping complex Java2D code in simpler builders. Andres Almiray announces release 0.4.5 of GraphicsBuilder with support for more than 60 filters. Two examples that show the power of JHLabs filters and the simplicity in which they are exposed in GraphicsBuilder can be found here and here. Andres also kicks off the first part of his tutorial on DZone, and Dave Cherry rounds up with the support for JFreeChart library.
  • Nazmul Idris continues his tutorials on SwingX components. This week he features the tutorials on task pane containers and busy labels.
  • Jesse Kuhnert writes a rather misguided rant about Swing. The three points that he mentions as Swing’s worst parts are quite easily addressed. The core layout managers are indeed terrible – but what about the great third-party layout managers? A possible analogy for the web development would be doing everything in pure HTML (and its deficiencies with using tables for everything) instead of using much more flexible CSS layouts. The next point is about rendering hints and has been addressed in Chet’s blog. One can also employ more advanced techniques such as bytecode injection. And since when web developers had access to rendering hints? The last point is about signals and slots. Not sure how this relates to Swing. Perhaps something like Event Bus project?
  • Fabrizio Giudici continues one of the points touched on in the previous item. His post shows how he is using bytecode injection to add property change support to Java beans.

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

  • Alexander Potochkin continues his work on the advanced overlay functionality. His latest entry describes a solution for disabling Swing containers, including blocking mouse events, focus transitions and keyboard actions. While the proposed solution uses a clever trick (calling JComponent.print() instead of JComponent.paint() to address the double-buffer quirks on some containers), you’ll find some interesting discussion in the comments section. Some applications will result in incorrect painting on components that provide custom implementation of print() and the specific print methods like printComponent().
  • Ben Galbraith kicks off an interesting discussion on the quality of AWT font rasterizer. I don’t agree with his recommendation of choosing the UI font based on the rendering quality (especially since the quality is very subjective). If anything, the font family, size, style and rasterization is what makes Swing applications stand apart (and not in a good way) from the native applications, even more than colors and skins do. This is why the native text rasterizer is so important, especially coupled with platform-specific font policy lookup.
  • Jeff Friesen writes an overview of the Balloons Tip project at java.net.
  • Patrick Gotthardt announces the first beta drop of version 1.1 of Pagosoft look-and-feel.
  • Vincent Cobra announces his new project that aims to provide a file chooser component based on the Apache Commons VFS library.

I had only two things on my Java desktop wishlist for 2008 – cross-platform support for H.264 / FLV formats and converters / viewers for competing markup formats. To quote myself on the second wish

You know what i’m talking about – those pesky competitors that have 99.9% percent of the consumer-facing rich desktop market. Flash / SWF, Flex / MXML and WPF / XAML. Each has its own set of designer tools for creating rich content. Each has armies of professional designers versatile in using those tools, in addition to Photoshop, Maya and others. Do you really expect them to master yet another (unproven) designer tool?

If JavaFX wants to have a fighting chance, it needs to provide a simple migration path. A path that allows taking an existing Flex / Silverlight application and importing it to JavaFX (at least the visuals).

Is it possible that this is becoming a reality? Here is what James Gosling said to Register Developer during the Mobile & Embedded developer day:

We are putting a lot of effort into interoperability with the Adobe tools – a lot of the Adobe tools are wired into the neurons of the artists of the world, […] We are not trying to be a completely isolated island that has all the tools for everybody.

Obviously, this is completely open to interpretation and speculation, and we’ll have to wait for the grand announcement(s) at this year’s JavaOne. My read on this is that Sun will provide a set of plugins to Adobe tools that will allow exporting art as JavaFX and SceneGraph code. And instead of focusing on creating visual tools for the designers, Sun will put the effort in the programmer’s half of the tool chain.

Only time will tell…