Swing tips and tricks

Some days go I was given the task to customize the Java Swing widgets for a project in our company. The default look and feel of a JDialog, specifically, has the Java logo trademark icon on the upper corner left, the close button on the right one and the title panel is painted according to the default MetalLookAndFeel probably. As an example, we have something like this:

We wanna have an option to change the title’s panel color, to remove the close button and not to have the Java trademark logo showing on the panel. The final JDialog should look like this:

I’ve thought it was a nearly difficult task, because I had to override a default look and feel and some hidden properties, sometimes difficult to find. Shame on me. Searching through some forums, I’ve found some interesting tips and tricks about how to customize a the entire dialogs of a Swing application, even without creating a look and feel or overriding an old one.

For your knowledge, here are some overridden properties to make the JDialog seems like the latter above. These properties let you define new colors for the active caption of your widgets, other font colors, custom family types and much more (for other properties see through the documentation API or the forums below).

UIManager.put(“activeCaption”, Color.BLUE);
UIManager.put(“activeCaptionText”, Color.WHITE);
UIManager.put(“InternalFrame.titleFont”, new Font(“Arial-12-i-2”, Font.BOLD, 11));
Border cuverdBorder = new LineBorder(new Color(210, 210, 210), 2, true);
dialog.getRootPane().setBorder(cuverdBorder);
dialog.getRootPane().setWindowDecorationStyle(JRootPane.PLAIN_DIALOG);
JDialog.setDefaultLookAndFeelDecorated(true);
JFrame.setDefaultLookAndFeelDecorated(true);
dialog.setUndecorated(true);

As a little example, below is the Java code to remove the close button from the panel’s title. This little code snippet below traverses the component hierarchy, passed as a parameter, in a recursive method.

   1:public static void removeCloseButton(Component comp)
   2:{
   3:    if (comp instanceof AbstractButton)
   4:    {
   5:        Action action = ((AbstractButton) comp).getAction();
   6:        String cmd = (action == null) ? "" : action.toString();
   7:        if (cmd.contains("CloseAction"))
   8:        {
   9:            comp.getParent().remove(comp);
  10:        }
  11:    } else if (comp instanceof Container)
  12:    {
  13:        Component[] children = ((Container) comp).getComponents();
  14:        for (int i = 0; i < children.length; ++i)
  15:        {
  16:            removeCloseButton(children[i]);
  17:        }
  18:    }
  19:}

Here are some Sun forums I’ve searched so far to find the possible helps for this solution:

Hope you make use of those tricks in your projects :-).

Google announces Android

Google ended up the mystery and announced a mobile free development platform, called Android and not a GPhone, as someone would expect. This platform leverages the capacity of building rich mobile applications and service, promoting rich content for the consumer. It includes an operating system, user-interface and applications, letting developers build new mobile services equally, in a meaningful way. As Google says,

“We see Android as an important part of our strategy of furtheringGoogle’s goal of providing access to information to users wherever theyare. We recognize that many among the multitude of mobile usersaround the world do not and may never have an Android-based phone. Ourgoals must be independent of device or even platform. For this reason,Android will complement, but not replace, our longstanding mobilestrategy of developing useful and compelling mobile services anddriving adoption of these products through partnerships with handsetmanufacturers and mobile operators around the world.”

Dear readers, would it be the Web2.0 mobile revolution?

The war between Apple and developers

Cédric has posted an interesting point of view about the war between Apple and the developers. This war started when Java developers knew Leopard doesn’t include Java. Cédric resumed Apple’s position in one paragraph, saying:

“What is needed in Cupertino is a radical change in attitude. Dropping the elitist behavior is a mandatory path to success for Apple, and listening to hordes of developers banging at your door is a good first step. Apple doesn’t need to implement Java, but they could show a little bit more willingness to work with whoever is interested in helping take their platform to the next level. Dumping Objective C is probably not an option, but making other languages first-class citizens on a top-notch IDE would undoubtedly go to great lengths toward making this goal a reality (ask Microsoft how Visual Basic and Visual Studio worked out for them). I’d start with C++, maybe C and even some sort of Basic. Hell, just swallow your pride and create a Visual Basic clone for Mac OS.”