Here are some Swing links that you might have missed during the last week:
- Jeremy Wood has been a busy blogger this week. First, he compares different approaches in using spinners for specifying length measurements in different units. Next, he presents a dialog to layout several tiles / cells on a print page. And finally, he closes the week with a partial implementation of Mac “Windows” menu that tracks the list of currently open top-level windows and their respective states.
- Olivier Gout has a prototype of WYSIWYG theme designer for Nimbus. The “official” Nimbus designer promised at this year’s JavaOne is nowhere in sight, and only time will tell whether this new attempt will outlive the growing list of Synth designers / builders mentioned in Swing Links of the Week edition of March 23, 2008.
- Patrick Ahlbrecht has a skeleton implementation of persisting window geometry and toolbar location between successive launches of an application window.
- Kai Toedter has written a demo application that shows how to use OSGi Declarative Services (DS) and Spring Dynamic Modules (Spring DM) together with Swing UI (and the Swing Application Framework, JSR 296). The Person Manager project is licensed under EPL.
- William Chen has announced his work on the Visual Swing Designer for Eclipse.
- Adam Bien continues to favor Swing over SWT in his two-part attack. Starting with how to make your Swing coding more efficient, he then continues to address the perceived Swing weak spots. From reading these and previous postings, looks like Adam holds a particular dislike towards SWT tables, and i couldn’t disagree more. Just like it takes quite some time to fully understand your way around Swing tables (including models, renderers, editors, listeners and much more), it takes a little bit more than a few suggested hours to switch to the SWT / JFace approach. This is not to say that one is clearly better than the other. It’s just that if you come with prejudice or a very strong knowledge in one, the other will seem clunky, over engineered and convoluted.
- Two interesting Swing-related threads on the Google group for Javaposse. The first addresses the misunderstanding of the painters issue and the community handling throughout the entire process, and the second calls for community questions on JavaFX.
- Andres Almiray has announced release 2.0.1 of JIDE Builder and 0.1 beta release of GfxPad.
- Roman Kennke continues his work with Java2D, writing about first Java2D pipeline implementation on top of the DirectFB hardware abstraction layer.
- Ken Orr has announced release 0.9.3 of Mac Widgets for Java. Major new addition in this release – iApp style scroll bars. Is it me, or is the reflection of the new scroll bars incorrectly flipped?
- Clemens Eisserer reports that his XRender pipeline has been integrated into the IcedTea fully open sourced port of OpenJDK.
In three days, JavaFX Desktop 1.0 will be officially released. I have been skeptical about JavaFX over the last few months, and while this may be attributed to general inclination of programmers towards being “entrenched” in the technologies that they know, there are other reasons as well. Aside from a few unnamed technology partners that were participating in shaping the capabilities of this release, the community has been effectively shut from lending its hand in commenting, testing and evolving the platform. We have long heard about “being blown away” by the new functionality being brought by JavaFX to the RIA market, and this week we will finally see if it is going to live up to the marketing hype.
Personally, i will be very glad to see at least one out of the following ten items being available for JavaFX, as well as cross-platform Swing applications come December 4:
- 6u10 / 6u11 for Apple – [update] see bug 6761033 for some interesting news.
- Full java lightweight rendering of SWF files even without installed Flash engine
- Full java lightweight rendering of H.264 files even without installed codecs
- Adaptive video streaming based on the client CPU and network utilization
- Video capture and creation
- Fully skinnable lightweight browser component based on WebKit or Mozilla / Gecko
- Inclusion of form-oriented layout manager
- Support for high level shader language (HLSL) for hardware accelerated custom effects
- Nimbus designer
- JavaFX.com with JavaFX-only applet driven content
And is it me, or are we going to see Sun ditching its own module initiative and move towards restructuring JDK as a collection of OSGI bundles?
The latest addition in the Flamingo component suite is support for minimizing the ribbon. This has been one of the items on the roadmap for version 4.0 (code named Fainnear), and is now available in the latest 4.0dev drop of Flamingo core and 5.1dev drop of Substance Flamingo plugin.
There are three ways to minimize and un-minimize the ribbon:
- Application code can use the new JRibbon.setMinimized API
- User double-clicking a task toggle button
- User pressing Ctrl+F1 key stroke
Here is a screenshot of a ribbon when it is not minimized:

When the ribbon is minimized in one of the three ways mentioned above, only the task bar and the task toggle button bar are shown. The ribbon bands of the currently selected ribbon task are hidden. Note how the main content of the frame (delineated with the Word-style ruler bands) gets expanded to occupy the area of the ribbon bands:

When a task toggle button is single-clicked, the ribbon bands of the clicked task are shown in a popup overlay without shifting the main content area down:

The ribbon tasks in the popup overlay have the same cascading popup support as the usual (non-minimized) ribbon tasks. Here is a extended popup menu of a Popup button from the first ribbon task:

If you want to see the scrolling in action under the core look-and-feels, run the following WebStart demo:

If you want to see this functionality under Substance, run the following WebStart demo:

If you want to test the new functionality in your applications, you would need the following (the last two only for applications running under Substance look-and-feel):
Your feedback is, as always, greatly appreciated.
As the name of this very blog implies, perhaps the most enjoyable part of my work on Substance and Flamingo is polishing the visuals of the different controls. And while the main emphasis of release 4.0 of Flamingo (code-named Fainnear) is to close the existing functional gaps, this will most certainly not come at the expense of the visuals.
First, here is a screenshot of an enhanced popup menu under Nimbus look-and-feel before:

And here are the new visuals:

In this specific example, the differences are somewhat unnoticeable. You can see that the insets of Format button and Apply Styles menu item are a little bigger, and that the ribbon gallery buttons (up / down / expand) are more consistent with the standalone buttons and have only one-pixel separator line between them.
This polishing is much more noticeable on command button strips, especially under look-and-feels that have non-zero padding around them (such as Nimbus). Let’s start with the Windows look-and-feel under Vista. This is before:

and this is after:

This is the same command buttons strips under Nimbus before:

and after:

And finally, the same command button strips under Synthetica Blue Steel before:

and after:

The new visuals also apply to vertical command button strips. A core example can be found in the ribbon galleries that show the up / down / expand strip on the right hand side. Here is how it now looks under Nimbus:

and Synthetica Blue Steel:

Applications that wish to use the “segmented” appearance for command buttons outside the command button strips (akin to the “JButton.segmentPosition” client property supported by Aqua look-and-feel) can use the new AbstractCommandButton.setLocationOrderKind API. When you’re placing buttons inside a command button strip component, there’s no need to use this API explicitly.
Finally, the latest 4.0dev drop provides even more control over scaling the inner layout gaps of command buttons. The new setHGapScaleFactor and setVGapScaleFactor APIs on the AbstractCommandButton and JCommandButtonStrip classes allow applications to fine tune the “density” of command buttons. This is especially relevant for command button strips.
By default, buttons in horizontal command button strips use hGapScaleFactor of 0.75, and the buttons in vertical command button strips use vGapScaleFactor of 0.75. This makes the “kerning” between the adjacent buttons 25% smaller, accounting for gaps on both sides of the inter-button separators.
The following screenshot illustrates the horizontal and vertical gap scale factors on two different command button strips under Nimbus look-and-feel:

The top three rows have the same vertical gap scaling, but the horizontal gap scaling is different. The bottom three rows have the same horizontal gap scaling, but the vertical gap scaling is different. The gap scaling is supported on vertical command button strips as well:

And finally, Substance plugin for Flamingo supports the new functionality as well. Here are the horizontal button strips under Substance Business skin:

and the vertical button strips:

Here, you would notice that in addition to one-pixel separator between the adjacent buttons (that was already present), there are also inner one-pixel lighter contours on both sides of the separator.
If you want to test the new functionality in your applications, you would need the following (the last two only for applications running under Substance look-and-feel):
Your feedback is, as always, greatly appreciated.
In the comment section on the last entry, Viswanath has asked whether the next release of Flamingo is nearing. I do not have definitive answer to this question, as the goal of release 4.0 of Flamingo is to close all the existing functionality gaps. The original internal plan was to allocate 20 weeks for this release cycle, placing the final release at the end of January 2009. For this release i will follow the same cutoff dates as for Substance releases: release candidate two weeks before the final release, and core feature freeze four weeks before the release candidate.
This would currently place the core feature freeze in mid December, and this may prove a little over optimistic. Instead of shrinking the cool-off period between the core feature freeze and release candidate, especially given significant amount of new functionality, the final release may shift a few weeks into February 2009. This should give enough time for both the development of the missing pieces, and community feedback on the new functionality.
On a related note, JIDE has regrettably decided to stop their work on ribbon component. Competition is always good, and not only for the potentials users. Substance has benefitted greatly not only from the prior work (especially Quaqua and Looks), but also from the ongoing development of Nimbus and Synthetica. While i might not have always agreed with the marketing pitches (especially the 56K number for Nimbus which is quite irrelevant since it cannot run outside 6u10), the competition has created a welcome and tangible pressure that ensured continued work on improving and evolving various aspects of Substance.