While most applications do not benefit from changing the visual appearance (skins) at runtime, it is a valuable tool during the design phase of the project. There are two levels of visual changes for Swing applications – switching to a different look-and-feel by using the UIManager.setLookAndFeel call, or switching to a different skin in the skinnable look-and-feels.

Substance look-and-feel provides a few APIs that allow querying the available skins and changing the skins on the fly. Here is the list of steps that you need to do to add a combobox selector that shows all the available skins and changes the global Substance skin on selection change:

• Use the getAllSkins() API to populate the combobox with the list of all available Substance skins.
• Use the getCurrentSkin() API to select the combobox entry that matches the current Substance skin.
• Since the model entries behind the combobox are <span style="color: darkblue;">SkinInfo</span> objects, extend the default Substance combobox cell renderer to use the display name of the skin.
• Finally, register an action listener on the combobox which gets triggerred on any selection change. The action listener uses the setSkin(String className) API to set the selected skin as the new global Substance skin. Note that there is no need to explicitly invoke SwingUtilities.updateComponentTree on all your windows after calling this Substance API.

The complete code is available in the CVS repository. For more information on working with Substance skins, see the updated skin documentation.

The development of the next 5.2 version of Substance (code-named Quebec) is wrapping up. You’re more than welcome to take the latest 5.2dev binary drops for a spin. The release candidate is planned for May 11, with the final release scheduled for May 25.

With the latest addition of multi-row functionality in the Flamingo ribbon bands, it is now possible to circumvent the deliberate restriction that was enforced previously. One of the main ribbon tenets states that UI controls should never be hidden or redisplayed (except contextual tasks) – you should rather disable / enable controls as necessary.

While it has been possible to hide / show controls before by wrapping a JPanel in a JRibbonComponent and changing the visibility state of the panel children, it has now become even easier under the new multi-row mode. I most certainly do not want to see such usage, and i do not have any plans to make code changes for scenarios that involve such usage.

However, i am a realistic person, and i understand that a determined developer armed with enough knowledge of Swing will find a way to circumvent restrictions that i place in the code. Even such draconian measures as tracking all hierarchy events in all JRibbonComponents and throwing exceptions when visibility changes are detected can be thwarted by ignoring / uninstalling the hierarchy listeners registered by the Flamingo UI delegates. I certainly do not want to go down that route, but i do want to ask you to respect the philosophy behind the ribbon and to not try cheating the APIs and the implementation. Doing so will make me even less open to provide additional ribbon APIs in the future.

< Prev Next >

A few hours ago an interesting changelist has made its way into the JDK 7 Swing branch. It definitely looks like the Nimbus designer will be available as part of JDK 7.

Unfortunately, it does look like this changelist does not contain all the files that are part of Nimbus designer (see below for the walkthrough), but hopefully this will be amended in the following days. In the meanwhile, here is what i’ve been able to do:

• Click on the zip link on the changelist page and extract the contents of the zip file. I’ve saved it in the C:\JTools\jdk7-src folder.
• Create a new Eclipse project. Point to C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\classes as source, and add all the jars in C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\libs as external jars.

As i said before, it looks like the changelist is not complete, and i haven’t been able to find the main class to run the designer itself. However, you can run the partial generation of Nimbus painters to get the feel of how that phase is working. Here are the steps:

Run the org.jibx.binding.Compile class passing the following two program arguments:

• C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\classes\org\jdesktop\swingx\designer\Designer.jibx.xml
  
• C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\classes\org\jdesktop\synthdesigner\synthmodel\SynthModel.jibx.xml

Copy the three .template files from C:\JTools\jdk7-src\jdk-c5cd40f1f596\src\share\classes\javax\swing\plaf\nimbus to C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\classes\org\jdesktop\synthdesigner\generator\resources

Run the org.jdesktop.synthdesigner.generator.Generator class passing the following arguments:

• -full false
  
• -skinFile C:\JTools\jdk7-src\jdk-c5cd40f1f596\src\share\classes\javax\swing\plaf\nimbus\skin.laf
  
• -srcDir c:\temp\nimbus
  
• -buildDir c:\temp\nimbus
  
• -packagePrefix org.nimbus
  
• -lafName Nimbus

At this point, the c:\temp\nimbus should have the generated painter classes. Note that if you pass the -full true, the generation will fail since some of the template files (such as LookAndFeel.template) are not part of this changelist.