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.

Substance 4.1 official release

November 12th, 2007

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

Applications that use or implement custom border painters and title painters should consult the instructions in the migration guide.

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

The documentation has been updated with the latest visuals and APIs. In addition, there are new tutorials on Substance painters and skinning of custom components.
Special thanks for bug reporting and testing go to Mikael Grev, Vincent Trussart, Kamil Paral, Klaus Rheinwald and Jean-Francois Poilpret.

A few screenshots of the new functionality in Substance 4.1:

The inner border painters and tab pane content borders in the Raven Graphite Glass skin:

The new Creme Coffee skin:

Full support for desktop resolution settings:

Automatic font policy for Gnome desktops:

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

  • John Zukowski provides an overview of using system tray in JDK 6.0. Judged by the comments, people do not know that you can use JPopupMenu on the system tray icon.
  • Alex Potochkin adds yet another useful tool to his SwingHelper project. This entry introduces a “visual debugger” painter that allows seeing what is repainted at runtime, and whether your application / custom components are repainting more than necessary.
  • Patrick Lightbody is having some problems with Swing applications (namely IntelliJ IDEA) under Leopard Spaces.
  • Daniel Spiewak has written an overview article on Fuse project that allows injecting external resources into custom Swing / Java2D painting code. Based on comments from Daniel and Romain, i am still not convinced that this approach is easier than writing a custom theme for an existing look-and-feel, at least for a big UI that needs consistency for all the visual elements.
  • Rafael Alvarez writes about yet another Swing layout manager. You can also read the manual that has more information on the syntax and the usage of the XMLGridLayout. The goal of this layout manager is “to provide all the power of GridBagLayout with the simplicity of an HTML table“.
  • Charles Tai has announced the new SwingRCP project. The goal of this project is to provide “a platform for developing applications based on the Eclipse Rich Client Platform (RCP).” This is a commercial product, and it remains to be seen whether it will be able to win the mindshares of either Swing or Eclipse RCP developers.
  • An interesting RFE has made its way into the latest binary build of Mustang Update N. RFE 6604856 provides a way to define a RepaintManager for the hierarchy of specified component. I have already discussed the good and the bad sides of RepaintManager as a tool for custom painting, and one of the biggest disadvantages is that RepaintManager is a global resource. It’s not immediately clear where this functionality will be used. My hope is that it was added for internal use in JavaFX (why wait until now? this limitation has been known for a very long time), and not for yet another JavaOne demo. A look at the sources reveals that the implementation is most probably in the new internal com.sun.java.swing.SwingUtilities3 class and its static setDelegateRepaintManager class. Hopefully, this will be formally exposed in Mustang Dolphin to allow using multiple repaint managers in a supported way.