One of the basic building blocks in the Flamingo component suite is the command button component. Extending the existing core push button, it adds significant functionality, such as support for split and menu button modes, resizable icons, flexible dynamic layout, custom popup panels and more. The official documentation has the detailed walkthrough, and here i will give a short overview of some of the main features.

As noted earlier, all Flamingo components are written to look consistent under existing core and third-party look-and-feels. While the screenshots in this post show the command button under the default Ocean look-and-feel, you can use this component under any other look-and-feel that your application is using.

The first screenshot shows a command button under different states. Note how the icon size, the layout and the text presence change – this allows the application and the layout manager to make effective decisions on how to best utilize the available screen estate:

In addition to the usual “action area” (which is the entire button area under the default kind – the same as the core JButton component), the command button can have the “popup area”:

The actual division between the action area and popup area depends on the button kind – in the screenshots below notice the difference in the second row. The Cut button is defined to treat the text as part of the action area, while the Copy button is defined to treat the text as part of the popup area:

There are two ways to configure what happens when the popup area is activated. The first way is the simple one – configure a listener that gets called when a popup menu is about to be shown. The application code doesn’t need to worry about the menu creation, location or lifecycle.

The second, and much more powerful method is to attach a popup panel to the command button. The popup panel allows showing any Swing component / container in a popup window:

As with the simpler core popup menus, the popup panels can be cascaded, dismissed with ESC key or mouse events and are accessible via a global manager (API + registering listeners).

You’re welcome to play with the latest 3.0dev drop of Flamingo and read the detailed documentation.

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

• Continuing the theme of Swing-“powered” applications running on JVM but written in another language, Shawn Crowley addresses the viability of JRuby as a realistic candidate for authoring complex desktop applications. It’s great to see that his experience is largely positive and he has no regrets in choosing this platform.
• Tim Dalton continues his series on building GUIs in Scala. This time, the “usual suspect” of UI demoes – a simple calculator.
• And to top off this part, Andres Almiray revisits his library of Groovy builders as the Groovy 1.1 release approaches. The entry on GraphicsBuilder is talking about adding mouse and keyboard support, and the entry on JideBuilder makes sure that it is updated and functional. The last entry is on GraphicsPad, which begs just two questions – what is it, and where are the screenshots?
• Jan Erik Paulsen continues his experiments with Photoshop Express clone, and is trying to come up with a new Substance-based skin. Dubbed “Titanium White”, it looks quite similar to the core Business skin from Substance with round button shaper.
• Alex Potochkin has technical details on the Rainbow application that we used for our join JavaOne presentation last year. As you can see, this application is still alive (hint-hint), and is still used by both of us to improve the libraries that it is using (JXLayer for Alex and Flamingo for me).

And a few product announcements as well:

• The JPen project is a library for accessing pen/digitizer tablets and pointing devices.
• Alex Ruiz has announced the release 0.7.0 of the FEST-Swing UI testing library.
• Dave Gilbert has announced the bugfix release 1.0.8 of JFreeChart charting library.
• Wolfgang Zitzelsberger has announced the release 2.6.0 of Synthetica look-and-feel. If you thought your favorite library was customizable, take a look at the customization documentation – with ten new client properties, this release has broken the 300 mark :)

Lately, there have been quite a few postings on the mailing list of Substance look-and-feel that ask how to change the default animation settings. This can be required for a number of reasons, including performance speedup and proper effects on custom application renderers. Following in the footsteps of the painter primer and skinner primer, the animation primer provides the necessary information that you need to configure custom animation settings for Substance-powered applications.

To bring richer user experience to Swing applications, look-and-feels that use the Laf-Widget library can use its flexible and powerful animation layer. The layer provides support for animating core and custom Swing components, including core animations (such as rollovers and selections), as well as custom animations (such as pulsating border of a focused text component).While the default animation settings (which transitions to animate, the animation speed, the set of components to animate) were selected to provide a consistent and pleasant out-of-the-box visual experience with zero application configuration, some applications might need to configure the animation settings.There are three techniques that the applications can use to change the default animation settings:

• <font color="darkblue">org.jvnet.lafwidget.animation.FadeConfigurationManager</font>
• <font color="darkblue">org.jvnet.lafwidget.LafWidget.ANIMATION_KIND</font>
• <font color="darkblue">META-INF/lafwidget.animations.properties</font>

Using the FadeConfigurationManager API

The <font color="darkblue">org.jvnet.lafwidget.animation.FadeConfigurationManager</font> is the first way to change the default animation settings. It provides the API to programmatically disable / enable core and custom animations. You can use the various <font color="darkblue">allowFades</font> and <font color="darkblue">disallowFades</font> on all controls, on all controls of the specified class or on a specific component. For example, here is how you can remove rollover and selection animations from the specific list:

JList list = ...; // create the list
FadeConfigurationManager.getInstance().disallowFades(FadeKind.ROLLOVER, list);
FadeConfigurationManager.getInstance().disallowFades(FadeKind.SELECTION, list);

where <font color="darkblue">org.jvnet.lafwidget.animation.FadeKind</font> is an instance of a core or custom animation kind.

Using the LafWidget.ANIMATION_KIND client property

The <font color="darkblue">org.jvnet.lafwidget.LafWidget.ANIMATION_KIND</font> is client property name for specifying the kind of animation on various components. The value should be one of <font color="darkblue">org.jvnet.lafwidget.utils.LafConstants.AnimationKind</font> enum. This property can be set either on component or globally on <font color="darkblue">UIManager</font>.

In order to compute the animation kind for some component, the component’s hierarchy is traversed bottom up. The first component that has this property set, defines the animation kind. Finally, if neither component not its ancestors define this property, the global setting on <font color="darkblue">UIManager</font> is checked. If there is no global setting, the default <font color="darkblue">LafConstants.AnimationKind.REGULAR</font> is taken.

The <font color="darkblue">LafConstants.AnimationKind.NONE</font> value can be used to remove all animations from the specific component (and its children) / globally. Here is how you can remove all the animations from a list:

List list = ...; // create the list
list.putClientProperty(LafWidget.ANIMATION_KIND, AnimationKind.NONE);

Using the META-INF/lafwidget.animations.properties resource file

The final way to configure the default animation settings is to bundle a <font color="darkblue">META-INF/lafwidget.animations.properties</font> text file with the application. Every line should be a fully qualified class name of a Swing component. At runtime, there will be no animations on a component if it is an instance of that class, an instance of class that is assignable from that class, or has a parent that matches the first two criteria.

Comparing the different techniques

There are different use cases for each one of the techniques.

• The <font color="darkblue">FadeConfigurationManager</font> provides a powerful way to allow or disallow the specific animation kind. However, if you want to remove all animations globally or on the specific component, it is better to use <font color="darkblue">LafWidget.ANIMATION_KIND</font> set to <font color="darkblue">LafConstants.AnimationKind.NONE</font>.
• If you want to configure the animation speed, you should use the <font color="darkblue">LafWidget.ANIMATION_KIND</font> and set it to either a core or a custom <font color="darkblue">LafConstants.AnimationKind</font>. A custom implementation can provide a non-linear cycle interpolation.
• The <font color="darkblue">META-INF/lafwidget.animations.properties</font> should be used when you want to disable animations of all kinds on all instances of the specific components. In the core implementation, it is used to disable all animations from list, tree and table renderers.

Yesterday i posted six screenshots divided in two groups and asked what is the difference. Most of the comments rightfully pointed out that the font rendering is different, and that the second group looks better in this area.

First, here is a screenshot that summarizes the difference in font rendering in those screenshots (the source code for this application is here, read the technical instructions below on how to run it):

The not-so-gentle hint in the frame title bears congratulations to Eugene Ryzhikov that said that the font rendering in the second group is “just like on Vista”. The first and third rows in the screenshot above are rendered by SWT (and hence by the OS), while the second and fourth rows are rendered byAWT / Java2D (applying the rendering hints as instructed by Chet Haase). The difference has been pointed out and discussed about eight months ago on this JavaLobby thread, but this specific screenshot doesn’t really do native rendering the justice it deserves.

First, note the stroke weights – SWT / native rendering is consistently heavier than in AWT / Java2D one. This puts less strain on the eyes in the long run. Second, pay close attention to the small letters ‘a’, ‘e’, ‘s’, pretty much all the digits and the symbol ‘@’. Java2D rendering is missing an entire pixel! And this specific screenshot is not even a good representation of a “real” UI, since it falsely skews the letter frequency and doesn’t show actual words.

Much can be said about statistics and how they can be bent both ways, but suffice it to say that, combined together, letters ‘a’, ‘e’ and ‘s’ account for more than 26% of an average English text. This means that on average, a Swing UI running on Vista and using the default Vista font (Segoe UI) has a lot of unnecessary inter-letter white space, which makes the texts less readable; the extra white space might cause the eye to perceive word boundaries where there are none. Combine that with lighter strokes and there – you have the reason why the WindowsLookAndFeel in Mustang under Vista still uses Tahoma for all the controls except menus. So much for the platform fidelity…

This issue has been on my mind ever since this comment by Karsten Lentzsch; i even had a chance to ask the Swing Java2D team about this during the Desktop Matters conference held on the next day of Karsten’s comment. Why not use SWT text rendering in Swing applications? Since the main strength of SWT is the native rendering (not only for texts), we will have the operating system rendering our strings, bringing the absolute fidelity in text rendering. And this is what is provided by the Bramble plugin for the latest 4.2dev drop of Substance look and feel (code-named Memphis).

Once you have the Bramble plugin in your classpath, along with the matching SWT jar and native library (see below for more technical details), Substance will automatically switch to native text rendering, turning this

into this

The actual implementation is a little bit more complicated than i originally thought. This is mainly due to the fact that in SWT you can’t paint anti-aliased text on a transparent background, like you can in Swing. See this discussion on the platform-swt-dev mailing list and this discussion on the eclipse.swt.forum for the reasons why. I’ll blog about this limitation and a few other differences between SWT and AWT text rendering later; in the meantime you can see the current implementation for more details.
Currently, the following components should have support for native text rendering:

• JButton and JToggleButton
• JRadioButton and JCheckBox
• JLabel including the default cell renderers for JTree, JTable, JList and JComboBox
• JTextField with simple view
• JTabbedPane
• Decorated title panes of JFrame and JDialog
• JMenu and JMenuItem
• JCheckBoxMenuItem and JRadioButtonMenuItem. Currently, the checkmarks are not shown (will be addressed)
• Components from the Flamingo component suite such as JCommandButton, JToggleCommandButton and JRibbon.

The implementation requires JDK 5.0 to run, and has been successfully tested under Windows Vista (where it makes the biggest impact). In addition, it successfully runs under Windows 2003 and should also run under Windows XP. Since there are no Windows-specific classes used in the Bramble text painter, it should also run under other OSes, such as Mac OS X and Ubuntu (pretty much everywhere SWT is supported).

To give your application a ride, you need to do the following:

• Download the substance-bramble.jar here and add it to the classpath of your application.
• Add the org.eclipse.swt.win32 jar to the classpath of your application. Bramble distribution bundles this jar from Eclipse 3.2.1 in the ‘lib’ folder.
• Extract the matching swt-win32.dll and add it to the java.library.path of your runtime configuration. Bramble distribution bundles this DLL from Eclipse 3.2.1 in the ‘lib’ folder.
• Configure your application to run under the latest 4.2dev drop of Substance look and feel.

The next steps are:

• Provide full support for all core Swing components, with possible exclusion of non-plain text components, such as HTML rendering
• Provide full support for all SwingX components
• Test and verify under Ubuntu 7.10
• Extend the current Windows font policy to use Segoe UI font under JDK 5.0 running on Vista
• Provide support for WebStart environment
• Provide support for the NetBeans module

The native text rendering coupled with the automatic platform-specific font policy lookup should help Substance-powered Swing applications turn into the first-class citizens on the Vista desktop. Many thanks go to Karsten Lentzsch for his pioneering work in this field.

You’re more than welcome to leave comments with your thoughts, suggestions and bug reports (first consult the current list of supported components above). The plugin is distributed under the Eclipse Public License (EPL). Hope you like it, happy Thanksgiving and see you on the other side of our trip to Hawaii :)