Carsten says in the comments to my previous posting:

all very nice and well, but from a business point of view right now the only interesting LnFs for me are Gtk and Windows XP. why are you missing both those two of all LnFs? makes me wonder…

Allow me to reiterate the last section in that entry:

i can go on and on with the screenshots, but you get the point. It can run under any core or third party look-and-feel without any special tricks in the application code and without writing any LAF-specific rendering

And to illustrate this, here are the components under Windows look-and-feel in Windows XP:

And the same components under GTK look-and-feel in Ubuntu 7.10:

As you can see, these look-and-feels are fully supported, including matching the fonts, desktop text rendering hints and dynamic layout that scales and adjusts with the font settings.

After quite a few months of preparations and planning, the Flamingo component suite project has a formal vision. Here is the list of goals for the version 3.0 that will be released in February 2008.

• To provide a small and cohesive set of powerful UI components that allow creating modern applications that provide visual functionality similar to or superseding that of Vista Explorer and Office 2007.
• To provide out-of-the-box consistent look across existing and future core and third-party look-and-feels with any specific application or implementation coding.
• To allow third-party look-and-feel vendors to change the appearance and behavior of the components according to the functionality of the specific look-and-feel (for example, animations).
• To respect the DPI settings of the current look-and-feel, scaling the components as necessary to account for different base font sizes.
• To follow the core Swing guidelines in the external APIs and the internal implementation details to ease the learning curve for users, developers and look-and-feel implementors.
• To provide clean and maintainable blueprints for creating custom production-ready third-party Swing components.

In order to meet these goals, the following changes will be made for the first source and binary drops of Flamingo 3.0dev that will be available early next week:

• The minimum requirement for the release 3.0 will be JDK 6.0.
• Components that do not conform to the first goal (such as wizard, file viewer and message dialog) will be removed from the distribution.
• The package structure, public APIs and class names will be changed to conform to the last goal.

In doing so, i’m following the three principles outlined by Seth Godin for small business success:

• Removing the functionality that was either partially or poorly implemented and not ready for production use.
• Willing to introduce binary incompatibilities and higher minimum requirements for greater long-term gain for both the project and the community.
• Believing that while other component vendors do not provide the target components, they cover the majority of other functionality required from modern Swing applications.

There hasn’t been a lot of new content on this blog over the past three weeks, and this entry is just to keep you in sync with what you can expect from the next development drop of the Flamingo component suite.

Here is a partial screenshot of the controls (ribbon, buttons and galleries) under the Metal / Ocean look and feel:

Here is the same component under Windows look and feel in Vista:

And under the Windows Classic look and feel:

What about Nimbus? Here it is:

What about the Looks family? Here it is under Looks Plastic XP:

And how about Synthetica? Here it is under Synthetica Blue Ice

and Synthetica Mauve Metallic:

And here it is under Pagosoft look and feel:

And here it is under Squareness look and feel:

OK, i can go on and on with the screenshots, but you get the point. It can run under any core or third party look-and-feel without any special tricks in the application code and without writing any LAF-specific rendering. Stay tuned for more over the next few days.

As Substance look-and-feel nears the official release 4.1 (scheduled for November 12th), i’m working on the missing documentation. This entry talks about the using the painter layer to skin custom components.

As mentioned in the painter overview, most of the Substance painting logic is abstracted into a set of painters. This not only allows preventing duplicate painting sequence in the Substance UI delegates. This also provides a painting layer for the applications that wish to paint custom components in a way that is consistent with other Substance visuals.

This applies in two major cases:

• Providing consistent painting for a standalone component suite, such as SwingX.
• Providing consistent painting for custom components and visual areas of a specific application.

Instead of trying to match the colors, gradients and animation sequences from the current Substance skin (which might change between various releases), applications can use the Substance painting APIs. This will result in code which is shorter, more maintainable and also produces consistent results.

Skinning primer

The following Substance APIs are most suited for painting custom components:

• Gradient painters
• Title / header painters
• Border painters
• Watermarks

Most of the Substance UI delegates use a combination of the above APIs. While the exact combination in the existing UI delegates is subject to change in between releases, you can study the core Substance code to see the main combination patterns.

The first pattern is watermark overlaying. The watermarks are painted on most Swing containers, and on some components as well. In simpler cases (such as <font color="darkblue">JPanel</font>), the watermark is painted on top of the gradient fill. In more complex scenarios, after the watermark has been painted, the fill sequence is repeated with lower alpha value. Here is an example of such a scenario:

In this scenario, while the regular controls and containers on the content pane are painted with the regular watermark, the frame header (title pane and tool bar) has less “intrusive” watermark painting. This is achieved by the following sequence:

• Using the header painter to paint the background gradient.
• Using the watermark to paint the current watermark.
• Using the header painter once again, this time with the <font color="darkblue">AlphaComposite.SRC_OVER</font> with alpha value of 0.5.

The second pattern is decorating. The header painters can be used to provide distinct painting to some containers, this setting them “apart” from the rest of the application. As the pattern name implies, this works best on specialized containers and visual areas that are situated along the window edges. Here is an example of SwingX <font color="darkblue">JXLoginDialog</font> component painted by the Substance SwingX plugin:

In this scenario, the <font color="darkblue">JXLoginDialog</font> has a “decoration” strip located along the top side of the window. To paint the background of this component, the custom UI delegate is using the current header painter, which results in a consistent appearance of the top portion of this dialog.Here is another example of this pattern, this time on the <font color="darkblue">JXStatusBar</font> component from SwingX component suite. Assuming that this component will be placed along the bottom side of the frame, the matching UI delegate in the Substance SwingX plugin uses the current header painter to provide a distinct appearance of status bar which is consistent with the title pane and menu bar:

The third pattern is border tracing. Those components that require consistent painting of borders or contours can use the border painter with the matching contour. Here is an example of border tracing in the <font color="darkblue">JRibbon</font> component from Flamingo component suite under the Substance Flamingo plugin: This UI delegate uses the border painter extensively to create the required visuals. Note the outer contour of the ribbon that also includes the selected tab button, and the inner contours of the ribbon tasks.Here is another example of this pattern, this time on the <font color="darkblue">JCommandButton</font> component from Flamingo component suite. The custom UI delegate uses the border painter to paint the button border (a simpler contour in this case):

The last pattern is gradient filling. It is used to paint the inner fill of custom components (along with the border tracing pattern to paint the component contour). This pattern uses the gradient painter with the matching contour. Here is an example of the <font color="darkblue">JRibbon</font> component from Flamingo component suite: In this example, the first toggle tab button (Write) is filled by the current gradient painter, providing a consistent appearance with the rest of the application controls. Another example is the previous screenshot (of the <font color="darkblue">JCommandButton</font>), where the button fill is painted by the current gradient painter as well.