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

• Luan O’Carroll writes about updates to the rollup bar component from the XUI framework. The functionality of the component seems to lie somewhere between the task pane container / collapsible panels of SwingX and the collapsed panels of docking frameworks. The links to the demo videos seem to be down, and it would be interesting to see a WebStart demo and learn how well the component integrates with core and third-party look-and-feels.
• Andres Almiray continues his work on the GraphicsBuilder for Groovy. This week he talks about advanced strokes (based on the code by Jerry Huxtable) and the wide variety of geometrical shapes.
• John Zukowski provides a simple overview of placing custom components on tabbed panes (available starting from JDK 6.0). Unfortunately, all the tutorials i have seen on the subject deal exclusively with putting close buttons on tabs. I would be very interested to hear about at least one another valid scenario for using custom components on tabs. If there is none – why this functionality hasn’t been restricted to, well, putting only close buttons?
• Angelo De Caro writes about release 1.4.0 of MyDoggy docking framework.
• software4java company announced availability of the adaptive menu component. The functionality of adaptive menus introduced in the Microsoft Office 2000 to Swing application has a few significant shortcomings addressed at length in this posting by the lead designer of Office 2007, Jensen Harris. While it is still available in Office 2007, it is turned off by default – if you’re thinking about including this functionality in your applications, you might want to reconsider it.
• Christopher Deckers makes quite an unexpected announcement on library that brings integration with an impressive collection of native components to Swing applications. Based on SWT (with the applying restrictions of target platforms and bundled native libraries), it already provides solutions for embedding web browser, Flash player and multi media player, as well as querying the native file associations and launching registered applications (which looks very much like the Desktop class introduced in JDK 6.0).

Sometimes, the application design requires displaying vertical (rotated) texts. While this is not a common requirement, and the usage of vertical texts must be kept to an absolute minimum, one should be aware of the possible technical solutions and the problems associated with them. This entry shows two possible solutions, accompanied by the screenshots and short technical explanations specific to LCD monitors with enabled subpixel anti-aliasing.

One way to draw rotated texts (by either 90 or 270 degrees) is to draw a horizontal text on an offscreen image, rotate that image by the relevant amount and draw it on the screen. Here is how it looks like (using the native text rendering provided by SWT):

If the texts look a little fuzzy, it’s not because your monitor has different subpixel settings. Here is a 400% zoom on one text:

What’s with the extra horizontal bluish lines? Those come from the original subpixel rendering of the horizontal text that takes advantage of the LCD physical structure, as explained and illustrated in this java.net article by Chet Haase. Unfortunately, this doesn’t work so well on image rotation – the”extra” blue pixels simply make the text fuzzy and much less readable.

What’s the alternative? Another way is to install an affine transformation on the graphic context that rotates all graphic operations by 90 or 270 degrees. The implementation here is a little bit more complicated, since the transformation needs to be preceded by matching offset translation. And here is how it looks like:

Zooming a little on one of the texts:

Now this is crisper than the first technique, it still is far from perfect. For comparison, here is the same exact text drawn unrotated:

Note the width of digit 0 – when it’s drawn horizontally, it has three pixels between the outer sides. However, when it’s drawn vertically, it has only two pixels. Looking back at the screenshot of vertical sliders, the labels look much less defined as compared to the usual Vista texts (under Segoe UI font).

I’m not really sure what causes the loss of pixel in digit 0. During the past few months working with Vista, i have to say that i never have seen a single native application (including Office 2007 and SWT-based Eclipse) using vertical texts anywhere in the UI. Perhaps the native font rasterizer was never optimized to handle this case at all…

In addition to about twenty core Substance themes, the theme pack plugin provides even more themes to create a unique look for your Swing applications. When you put the binary plugin in the classpath, the additional themes become available in the getAllThemes() API, and you can use them just like any other core theme.

As part of updating the licensing headers to 2008, i’ve also updated the screenshots of extra themes to reflect the latest visuals of Substance. Here are some of my favourites:

Belize

Brick Wall

Fauve Mauve

Mahogany

Orchid Alloy

Yellow Marine

The subject of native text rendering in Swing applications has been introduced on this blog about six weeks ago, and I already described some of the implementation details. The devil is, of course, in details (unless you’re working on whizzy demoes), and i’ve spent the last month working on all the issues mentioned in the original post. This post addresses the functionality that has been missing, talks about the unsupported cases and links to a WebStart demo (at the end).

Easier deployment and support for WebStart environment

With migration to release 3.3.0 of SWT and valuable help from the SWT dev mailing list (thanks, Dave), it is now much easier to configure Bramble and SWT. Browse to the SWT main page, download the relevant distribution (Bramble distribution bundles the Windows version) and add the swt.jar to your classpath. That’s it – no more need to muck with the java.library.path VM flag and no need to extract the native libraries from the SWT jar (like was the case in 3.2.1).

To use the native text rendering in your WebStart application, take the latest substance-bramble.jar and the matching swt.jar, sign them and you’re ready to go. Note that if you’re using the jar from Eclipse itself, it’s already signed. Although it’s possible to use jars signed by different parties, I had security access exceptions on using the SWT jar from Eclipse. If you use the jar from the SWT main page, it works flawlessly (see the WebStart link at the end of this entry). If you need your application targeting multiple platforms, you’ll need to bundle the matching SWT jars and use the resources JNLP tag accordingly.

Support for all core Swing components

The latest binary and source drops of Bramble plugin provide support for all core Swing components with the following exclusions:

• Non-plain text components, including text panes and editor panes.
• HTML text.
• Titled borders.

The text on all these components (including HTML) is painted with the default core AWT text font rasterizer. The latest plugin version also provides support for painting rotated (vertical) texts which are used on vertical progress bars and sliders (with labels). Interestingly enough, the rotation transformations in AWT and SWT are different (rotation angles have opposite values, and hence the translation offsets are different as well).

Support for SwingX components

This will be done in the next Substance release. As a proof of concept, the latest SwingX plugin provides native text painting for the status bar components. As in the case above, all other SwingX components use the core AWT text font rasterizer.

Support for additional operating systems

While the primary target of Bramble plugin is Windows Vista (and the inadequate AWT rasterizing of the default “Segoe UI” font), this plugin is not Windows-specific. It has been successfully tested under Windows Vista, Windows XP, Windows 2003 and Ubuntu 7.10. If you encounter bugs (visual or exceptions) under other platforms (KDE, Mac and others which are supported by SWT), I would be very interested in hearing about it.

Incidentally, using the native text renderer can not only make the applications look better. The core AWT font rasterizer has its own bugs (as all software does). This bug report opened on Substance (under Ubuntu / Gnome) is caused by a bug in the default font rasterizer that fails on a specific non-Latin character (see the bug report for more details). Since this happens under the core GTK look-and-feel and Substance provides the platform-specific font policy lookup that is aligned with the GTK LAF font lookup, this bug is seen under Substance as well. While the visual quality of the AWT font rasterizer on “DejaVu Sans” is very close to the native text renderer and there isn’t much reason to bundle SWT and Bramble, at least in this case doing so makes the application run with no exceptions and look like it belongs to the specific desktop.

Under Windows Vista, the Bramble plugin will also instruct Substance to use “Segoe UI” font under JDK 5.0 as well. Unlike the AWT font rasterizer that did even worse job under JDK 5.0, the native text renderer doesn’t care. So, you don’t have to upgrade to JDK 6.0 to have your applications look good on Vista.

Demo

Clicking on the button below will launch the full Substance test application that uses Bramble plugin to render all the texts with the native renderer. Note that while the application itself is cross-platform, this specific JNLP file only uses Windows version of SWT (no need to leave comments that this specific JNLP doesn’t work on Ubuntu or Mac). It is signed since one of the tabs shows the file system tree. As you’ll see, the texts on the task panes (left hand side) do not have proper background – as mentioned earlier, full support for SwingX components will be added in the next release. So, click around and let me know if you see something fishy :)

You’re more than welcome to leave comments with your thoughts, suggestions and bug reports (but first make sure that you’ve read this entry in its entirety). The plugin is distributed under the Eclipse Public License (EPL). The release candidate is scheduled for January 21st, with the release scheduled for February 4th.