Color scheme association kinds in Substance look-and-feel are best illustrated by a simple example:

This is a screenshot of a <span style="color: darkblue;">JCheckBox</span> icon under 72 point font. This checkmark icon has three different visual areas: inner fill, border and the “V” mark. Each one of these areas is painted with a different color scheme, and this is allowed by using the relevant color scheme association kinds.

The <span style="color: darkblue;">org.jvnet.substance.api.ColorSchemeAssociationKind</span> is the base class for core and custom color scheme association kinds. Where is this class used?

  • The first usage is in the skin definition. The main SubstanceSkin APIs allow associating different color schemes with different visual areas of Swing controls.
  • The specific UI delegates query the component skin for the color schemes that match the relevant visual areas.

Let’s go back to the <span style="color: darkblue;">JCheckBox</span> icon example above. How do we use the color scheme association kinds to specify three different color schemes for painting this checkmark icon?

As detailed in the skin documentation, each skin has a number of color scheme bundles. This means that two checkboxes with the same model state (selected in out case) can have different visuals, depending on the decoration areas they reside in. In the definition of the specific color scheme bundle, you can specify different color schemes for different component states. This means that a selected checkbox can use colors different from those of a rollover selected checkbox.

In our case, we want to specify different color schemes for different visual areas of selected checkboxes in the default decoration area. The relevant method is the <span style="color: darkblue;">org.jvnet.substance.api.SubstanceColorSchemeBundle</span> is:

<span style="color: #000000;">registerColorScheme</span><span style="color: #000000;">(</span><span style="color: #000000;">SubstanceColorScheme scheme,</span><span style="color: #ffffff;"> </span><span style="color: #000000;">ColorSchemeAssociationKind associationKind,</span><span style="color: #ffffff;"> </span><span style="color: #000000;">ComponentState... states)</span>

  • The inner fill is specified by the <span style="color: darkblue;">ColorSchemeAssociationKind.FILL</span>.
  • The border is specified by the <span style="color: darkblue;">ColorSchemeAssociationKind.BORDER</span>.
  • The mark is specified by the <span style="color: darkblue;">ColorSchemeAssociationKind.MARK</span>.

Going back once again to the original image:

Here is the outline of the relevant configuration code:

SubstanceColorScheme activeScheme = ...;
SubstanceColorScheme defaultScheme = ...;
SubstanceColorScheme disabledScheme = ...;

SubstanceColorSchemeBundle defaultBundle = new SubstanceColorSchemeBundle(
activeScheme, defaultScheme, disabledScheme);

SubstanceColorScheme selectedBorderScheme = …;
defaultBundle.registerColorScheme(selectedBorderScheme,
ColorSchemeAssociationKind.BORDER, ComponentState.SELECTED);

SubstanceColorScheme selectedMarkScheme = …;
defaultBundle.registerColorScheme(selectedMarkScheme,
ColorSchemeAssociationKind.MARK, ComponentState.SELECTED);

Note that there is no explicit usage of the <span style="color: darkblue;">ColorSchemeAssociationKind.FILL</span> value. This illustrates the fallback mechanism. In this particular case, the second parameter to the <span style="color: darkblue;">SubstanceColorSchemeBundle</span> constructor is used as the fallback color scheme for inner fills under all component states. The fallback mechanism also extends to the other color scheme association kinds.

Here is the constructor signature of the <span style="color: darkblue;">ColorSchemeAssociationKind</span>:

<span style="color: #7f0055;"><strong>public </strong></span><span style="color: #000000;">ColorSchemeAssociationKind</span><span style="color: #000000;">(</span><span style="color: #000000;">String name,</span><span style="color: #ffffff;"> </span><span style="color: #000000;">ColorSchemeAssociationKind fallback</span><span style="color: #000000;">)</span>

The second parameter specifies what should happen when the color scheme bundle definition does not have an explicitly registered color scheme for the specific color scheme association kind under the specific component state.

For example, the <span style="color: darkblue;">ColorSchemeAssociationKind.MARK</span> has the <span style="color: darkblue;">ColorSchemeAssociationKind.BORDER</span> as its fallback. This means that if you want to use the same color scheme for painting both borders and marks, you need to only call the <span style="color: darkblue;">SubstanceColorSchemeBundle.registerColorScheme</span> API with the <span style="color: darkblue;">ColorSchemeAssociationKind.BORDER</span> value.

The registered associations are used by the Substance UI delegates during the component painting. Specifically for the checkbox, the UI delegate queries the three relevant association kinds (<span style="color: darkblue;">ColorSchemeAssociationKind.FILL</span>, <span style="color: darkblue;">ColorSchemeAssociationKind.BORDER</span> and <span style="color: darkblue;">ColorSchemeAssociationKind.MARK</span>) and uses the relevant painters (gradient and border) to paint the matching visual areas.

Applications that want to provide custom skinning of their UIs can use the following two supported APIs in order to get the relevant color schemes.

First, use the following API in <span style="color: darkblue;">org.jvnet.substance.SubstanceLookAndFeel</span> class to obtain the skin that should be used for painting your component:

<span style="color: #ffffff;"> </span><span style="color: #7f0055;"><strong>public static </strong></span><span style="color: #000000;">SubstanceSkin getCurrentSkin</span><span style="color: #000000;">(</span><span style="color: #000000;">Component c</span><span style="color: #000000;">)</span>

Then, use the following API in the obtained <span style="color: darkblue;">org.jvnet.substance.api.SubstanceSkin</span> class to get the color scheme for the relevant visual area:

<span style="color: #ffffff;"> </span><span style="color: #7f0055;"><strong>public </strong></span><span style="color: #000000;">SubstanceColorScheme getColorScheme</span><span style="color: #000000;">(</span><span style="color: #000000;">Component comp,</span><span style="color: #000000;"> ColorSchemeAssociationKind associationKind,</span> <span style="color: #000000;">ComponentState componentState</span><span style="color: #000000;">)</span>

Note that the second method should always return non-<span style="color: darkblue;">null</span> value, using the fallback mechanism discussed above to return the matching color scheme.

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.

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.

The games we play

April 13th, 2009

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 >