Flamingo component suite comes with a flexible and powerful component that hosts command buttons, providing support for button groups, single selection mode (for toggle command buttons), same icon state / dimension and automatic column layout. The official documentation for the base command button panel and file viewer panel have the detailed walkthroughs, and here i will give a short overview of some of the main features.

As noted earlier, one of Flamingo’s goals is 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. The command button panel and its extension, file viewer panel, address the functionality commonly found in file explorer applications.

Here is a simple file explorer that uses the breadcrumb bar and file viewer panel with button state set to medium:

Here, the icon for image files come from the file itself (thumbnails), while the icons for other mimetypes are taken from the latest SVN snapshot of the KDE Oxygen project.

Here is the same exact application with big icons:

The icons are properly scaled and the inner layout of the buttons changed to reflect the new button state. What about custom large icons?

The same functionality, only controlled by the flexible slider (on the left hand side of the application frame). Note that the bottom-right button has the icon based on the actual JPG contents (scaled down), while the other three buttons sport resolution-independent sharp visuals from Oxygen SVG images.

Here is the same application under the tiled state – with extra line of information on each file:

The last screenshot is from a sample SVN browser that uses the same icon computation approach, tiled state and extra line of information on each file (fetched from the SVN repository and set on the corresponding command button):

You’re welcome to play with the latest 3.0dev drop of Flamingo and read the detailed documentation on command button panel and file viewer panel.

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

• Jasper Potts posted an update on the Nimbus development progress. The screenshot shows the support for the different component sizes (using the same client properties as the latest Aqua drop). As the comments point out, there are quite a few visual inconsistencies which will be hopefully addressed (small and mini scroll bars, inconsistent scaling of arrow icons across different controls, small and mini indeterminate progress bars and text field shadows are among these).
• The latest drop of Dolphin addresses bug 6438179, providing correct implementation of tray service availability on Unix platforms. Backport to Update N highly desired.
• Danno Ferrin kicks off the slew of Groovy-related items with his overview of new Swing features in Groovy 1.5.
• Andres Almiray is back with a few postings of his own. Starting with CSS support in Swing / Groovy applications, he provides a little more information (and a screenshot) on GraphicsPad, and finishes off with updates on builders for WingS and Jide.
• Geertjan Wielenga blogs about integrating a YouTube player inside NetBeans IDE. A sad tribute to the lack of open-source video playback components in Java (he is using the commercial WebRenderer library). This is still on top of my wishlist for 2008, and is still foolish to hope for.

If you ever needed an argument against using a visual UI designer that enforces any logic on the code it creates, here it is:

In JBuilder 2007 CodeGear/Borland has completely dropped GUI editing support for the jbinit() stuff. So anyone who needs to update their old code need to rewrite it from scratch (which is a major risk) or handcraft it.

By show of hands – who would have thought in 1997 2000 (when JBuilder pretty much ruled the Java IDE landscape) that this could happen? Are you sure that NetBeans will outlive all the code that is being created by it as we speak? And by the way, the only complete visual UI editor that doesn’t impose any logic on the code it edits and is able to parse out even the most complicated custom forms that i have thrown at it comes from Instantiations. Now if only they could reduce the memory footprint from 400MB to something a little bit more realistic…

Following my entries on platform-specific font policies for Mac and Gnome, one of Substance users stepped up and provided an implementation that makes all Substance-powered Swing application pick the correct font sizes when running under the KDE desktop.

Here is a screenshot of a test application running under KDE desktop with font size of 10 and DPI set to 96:

and here is the same application, running under 120DPI, using font size of 10 except for menus which are configured to use italic 8:

The current implementation can be found in the CVS repository and was contributed by Paranoid (many thanks). It parses a few configuration files to get the DPI and font settings, providing fallback values in case these can not be found. Give the latest 4.2dev drop a try and let us know if you’re having any problems on KDE desktop.