Going dark

August 8th, 2008

This space will be quiet for the next two weeks, including the Swing links of the week series. See you on the other side of the vacation.

The goal of Flamingo project is to provide a small and cohesive set of powerful UI components with functionality similar to or superseding that of Vista Explorer and Office 2007. Command bar is one of the more complicated UI components in the Office 2007, and Flamingo’s JRibbon is the all-Java implementation of this component. It is already being used by a number of projects which provide valuable feedback on the missing parts and help in prioritizing their development. Recently, i have added two user-requested features to the JRibbon – modifying the contents of in-ribbon galleries and support for contextual tabs.

The documentation of JRibbon has been updated to bring it in-sync with the latest 3.1dev branch. If you’re new to this component, start with the overview and then delve into the specifics of each one of the ribbon’s building blocks.

To read more on modifying the contents of in-ribbon galleries scroll down to the “Dynamically changing gallery content” section in the ribbon bands page. To read about contextual task group, first read the page on creating a task group and then read the “Working with contextual task groups” section of the ribbon creation page.

Here is a screenshot of a ribbon with selected contextual tab. Note the vertical lines that separate the tasks in the two contextual groups. Also note the different background colorization of the task toggle tab and the top portion of the ribbon – this is done to provide visual indication that the currently selected task is a contextual one.

This marks the last new features for the version 3.1 of Flamingo. You’re more than welcome to download the latest 3.1dev drop and try it in your applications. The release candidate for Flamingo 3.1 is scheduled on September 1 with the final release scheduled on September 15. Click on the button below to launch a demo of JRibbon component in action (requires Java 6).

Project LightBeam was created a few months ago to assist Swing look-and-feel developers to reliably measure performance aspects of their libraries. LightBeam has a collection of static and dynamic scenarios that test different aspects of painting and tracking changes on core Swing components making it easier to identify performance bottlenecks and helping prevent performance regressions after introducing new features. LightBeam has been extensively used throughout the development cycle of version 5.0 of Substance look-and-feel to bring it in line with other core and active third-party look-and-feels.

An unexpected and welcome usage of LightBeam comes from the XRender Pipeline project that aims to create a new Java2D rendering pipeline based upong the X11 XRender extension. This project is part of OpenJDK Community Innovators’ Challenge that has reached the submission deadline yesterday, and is lead by Clemens Eisserer. The benchmark page of XRender project uses two third-party open-source benchmarking suites – MigLayout swing benchmark and LightBeam. Here is one of the benchmark charts comparing the performance of X11 and XRender pipelines under LightBeam (unfortunately misspelled):

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

  • Jon Lipsky is back from a two-year long blogging hiatus and he writes about extending the RelativeLayout from James Elliott’s 2002 article.
  • Santhosh Kumar is back as well (he’s not been blogging about Swing since last August), and this time he brings the auto-snap split pane divider. The solution is very simple, but i’m not sure of the usability of this particular feature. In the past, i always found the different auto-snap behaviors (such as windows in desktop managers or connectors in Visio) to stand in my way most of the time, leading me to fight with the UI. On the other hand, auto-snap in sliders is quite a useful features to restrict the input domain to a small discrete subset.
  • JavaSwing.net continues its series of tutorials on Swing text components, and this time they write an introduction to working with JFormattedTextField component.
  • Gregg Bolinger has an implementation of application wide hotkeys. It uses a custom EventQueue that inspects all KeyEvents and consumes those keystrokes that it sees as the custom hotkey launchers. If you decide to follow this route, be sure to read Hans Muller‘s post on the mailing list of AppFramework project from last October:

The downside is that I’ve spoken with the AWT technical lead and he’s suggested that using EventQueue.push() is deadlock-prone. That is, the area of code that deals with EventQueues is quite complex and there may be unknown bugs that could cause deadlocks.

  • And finally, Ken Orr tracks an interesting problem of providing different visuals for controls in active and inactive windows. His solutions include checking Window.isFocused in various painting methods (such as JPanel.getBorder and JLabel.getForeground) and tracking the changes to “Frame.active” client property.