From Pain to Gain: Swing and the NetBeans Platform in the Real World

The Look & Feel

The predefined Java look and feels are getting better with each JDK release, but sometimes you need a special LAF. For instance, dealing with photography you need a clean GUI that doesn’t distract the user, and a darkish theme (where all the used colors are rigorously shades of gray), so as not to disturb a correct perception of colors.

Since JDK 1.4, the UIManager class allows you to plug different look and feels with minimal or no impact on existing code. As the class is a part of the standard Swing API, there are a lot of compatible LAFs that can be easily plugged into your app.

If you find a look and feel that you like, you can install it into NetBeans (and of course into your NetBeans Platform application) with a simple command-line switch:  

--look-and-feel <name of the L&F class>

After some tests, I decided to keep the native look and feel for every piece of the GUI except for the main window, where I just changed the component colors (Mac OS X is a special case; see below). The typical blueMarine look and feel is illustrated in Figure 10.

Figure 10. Using a dark color scheme in the main window and a regular scheme in popups.

As you know, changing the colors of a Swing component is usually a matter of c.setForeground() and c.setBackground(). Since the NetBeans Platform is Swing-based, things aren’t much different. But there are a few exceptions. For instance, these standard methods don’t work on ListView (one of the most used view components for Node objects). In blueMarine, this was solved with the code in Listing 7, which first retrieves the inner JList and then changes its properties as needed. Similar code works with tree-based components (which share the same problem).

public class EnhancedListView extends ListView {

    protected JList jList;

    @Override
    protected JList createList() {
      jList = super.createList();
      jList.setOpaque(isOpaque());
      jList.setBackground(getBackground());
      jList.setForeground(getForeground());
      return jList;
    }

    @Override
    public void setBackground (Color color) {
      super.setBackground(color);
      if (jList != null) {
        jList.setBackground(color);
      }
    }

    @Override
    public void setForeground (Color color){
      super.setForeground(color);
      if (jList != null) {
        jList.setForeground(color);
      }
    }

    @Override
    public void setOpaque (boolean opaque){
      super.setOpaque(opaque);
      if (jList != null) {
        jList.setOpaque(opaque);
      }
    }

}                   

I found another problem with tree-based components: even with the code shown before, tree cells were rendered in black and white. Again, inspecting the sources, it was easy to find the cause: NetBeans’ trees usually have a special cell renderer which does many things, such as supporting HTML rendering (so you can use multiple text styles); the cell renderer also chooses a color scheme that contrasts well between the foreground and the background. This is a clever idea in most cases, but not when you want to fine-tune your colors. The workaround was implemented by the few lines shown in Listing 8. Here’s how you install the patched renderer:

PatchedNodeRenderer nodeRenderer = new PatchedNodeRenderer(tree.getCellRenderer());
tree.setCellRenderer(nodeRenderer);

class PatchedNodeRenderer extends DefaultTreeCellRenderer {

  private TreeCellRenderer peer;

  public PatchedNodeRenderer (final TreeCellRenderer peer) {
    this.peer = peer;
  }
 
  @Override
  public Component getTreeCellRendererComponent (final JTree jTree,
      final Object object, final boolean selected, final boolean expanded,
      final boolean leaf, final int row, final boolean hasFocus)
  {

  final Component component = peer.getTreeCellRendererComponent(
        jTree, object, selected, expanded, leaf, row, hasFocus);
        component.setBackground(
        selected ? getBackgroundSelectionColor() : getBackgroundNonSelectionColor());
        component.setForeground(
        selected ? getTextSelectionColor() : getTextNonSelectionColor());
        return component;
  }

}

Regarding the look and feel, Mac OS X raised some particular issues. Mac users, who are really picky about aesthetics, noticed some time ago that even the Java implementation created by Apple does not accurately reproduce the operating system look and feel. This prompted the creation of a third-party product, named Quaqua, which fixes all the problems and implements a pixel-accurate Aqua GUI. (Actually the problems go beyond pixel accuracy: for instance the Java JFileChooser under Apple’s Mac OS LAF is terrible in comparison to the native one.) As Quaqua is a regular look and feel handled by the UIManager class, its integration in blueMarine was not a problem, with the exception of a few Quaqua issues that were quickly fixed by the project’s developer.