The second point is there seems to be different answers for Windows and Unix and good arguments that maybe they should not be the same so let me start a new poll with them split and see if I am right. I will split the poll into 3 categories Windows, Unix GTK and Unix KDE. I am not quite sure how we detect between GTK and KDE but sure we can find a way

Again If you have a strong feeling one way or another then please explain in a comment below as we would love to hear. All your votes and comments will be taken into consideration when we make the final discussion.

If you have a strong feeling one way or another then please explain in a comment below as we would love to hear. All your votes and comments will be taken into consideration when we make the final discussion.

Update
I have closed this poll and opened 3 new ones on the post Breakdown of what should be default LAF for Java 7. So follow that link if you would like to vote.

Nimbus: The New Face of Swing TS-6096

Presenter: Richard Bair, Sun Microsystems, Inc.; Jasper Potts, Sun Microsystems, Inc.

Nimbus is the stunning next-generation cross-platform look-and-feel for the Java platform, perfect for skinning Swing components in existing applications and new FX applications. In this session, two Nimbus developers guide you through using Nimbus to create beautiful modern applications. They cover the basics of using Nimbus in your Swing applications and also discuss using the new Nimbus Designer visual design tool for extending Nimbus and styling custom components. Finally, they show how to brand your applications with completely custom look-and-feels extending Nimbus.

Nimbus properties follow some rules and you can not only use the property keys that we have added in as default but you can create your own. Nimbus Look and Feel scans the UIDefaults table when ever you add a property with UIManager.put(<<key>>,<<value>>) then updates its internal state. When that new property matches the current state of the component it applies to then it will be applied to that component. Properties cascade like CSS and the most specific matching one is used.
Example:

• foreground = Color.BLACK
• Label.foreground = Color.BLUE
• Label[Disabled].foreground = Color.GRAY
• "SomeLabel"[Disabled].foreground = Color.WHITE

In these examples foreground applies to the foreground of all regions of all components, Label.foreground applies to only Label components, Label[Disabled].foreground applies to only Label components in the Disabled state. "SomeLabel"[Disabled].foreground applies to all components named “SomeLabel” that are in the disabled state. Hopefully that also explains the different ways you can write a rule to match a Component. The only 2 cases that are not covered here are Component.Region.foreground which lets you specify a sub-region of a component and ComponentA:ChildComponentB.foreground which lets you specify a ChildComponentB contained within ComponentA. You can see many examples of these in the complete table below and then play with writing your own. For example you can use the “name” property of a component in a similar way to “class” in CSS, say naming a bunch of buttons “hotButton” and then specifying new rules for them in the defaults table. I already explained in my last blog how you can override the global defaults on a single instance bases which matches the “style” attribute with HTML CSS.

Colors in Nimbus are derived, which means there are a core set of colors which are constants and all the other colors are calculated from those. This means you can simply change those and the 1000s of other colors that are related and used in the painters will update to reflect the new base color. These colors are shown in the “Primary Colors” section of the table. The colors in the “Secondary Colors” section are derived from those in the “Primary Colors” section but themselves are used as the base colors for other colors. You may need to change the secondary colors to tweak the results of changing the primary ones if you are not happy with the results. You can you derived colors in your own code as well so that you colors can change when the primary colors change. This will allow you to make your application color theme-able idea for white label branding etc. The method you need is on NimbusLookAndFeel called getDerivedColor :

/**
 * Get a derived color, derived colors are shared instances and is color
 * value will change when its parent UIDefault color changes.
 *
 * @param uiDefaultParentName The parent UIDefault key
 * @param hOffset             The hue offset
 * @param sOffset             The saturation offset
 * @param bOffset             The brightness offset
 * @param aOffset             The alpha offset
 * @param uiResource          True if the derived color should be
 *                            UIResource, false if it should not be
 * @return The stored derived color
 */
public Color getDerivedColor(String uiDefaultParentName,
               float hOffset, float sOffset, float bOffset, int aOffset,
               boolean uiResource)

Hopefully the rest will make sense as you read though the table and look at all the examples. After that its just a matter of try playing with some and see what you can do. I hope you see that power in this that Richard Bair and I designed and hoped would be useful. The complete defaults properties table is way to big to include in this post so I have put it on a separate page.

• Nimbus UIDefaults Properties List

If you would like to see how I made this list, here is the code that creates the html.

NimbusBrowser.java

All of the Nimbus skin comes from a set of properties in the UIManager defaults table. The keys we will be changing for this example are:

• “Slider.thumbWidth”
• “Slider.thumbHeight”
• “Slider:SliderThumb.backgroundPainter”
• “Slider:SliderTrack.backgroundPainter”

You can customize the look for a Component either globally for all instances of the component or locally for a single component instance. To change all sliders globally you can set these properties using UIManager.put(key,value) but in this example I will just set them locally for a single slider. To set UI defaults localy for a single component instance you need to create a UIDefaults map, insert you properties and then set it as a client property on the component:

                JSlider slider = new JSlider(0, 100, 50);
                UIDefaults sliderDefaults = new UIDefaults();
                ....
                sliderDefaults.put(<<key>>,<<value>>)
                ....
                slider.putClientProperty("Nimbus.Overrides",sliderDefaults);
                slider.putClientProperty("Nimbus.Overrides.InheritDefaults",false);

The “Nimbus.Overrides.InheritDefaults” key states if the values in “Nimbus.Overrides” should be merged with the defaults(false) or replace them(true). So next some examples for what properties we should set to skin the slider:

                sliderDefaults.put("Slider.thumbWidth", 20);
                sliderDefaults.put("Slider.thumbHeight", 20);
                sliderDefaults.put("Slider:SliderThumb.backgroundPainter", new Painter() {
                    public void paint(Graphics2D g, JComponent c, int w, int h) {
                        g.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
                        g.setStroke(new BasicStroke(2f));
                        g.setColor(Color.RED);
                        g.fillOval(1, 1, w-3, h-3);
                        g.setColor(Color.WHITE);
                        g.drawOval(1, 1, w-3, h-3);
                    }
                });
                sliderDefaults.put("Slider:SliderTrack.backgroundPainter", new Painter() {
                    public void paint(Graphics2D g, JComponent c, int w, int h) {
                        g.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
                        g.setStroke(new BasicStroke(2f));
                        g.setColor(Color.GRAY);
                        g.fillRoundRect(0, 6, w-1, 8, 8, 8);
                        g.setColor(Color.WHITE);
                        g.drawRoundRect(0, 6, w-1, 8, 8, 8);
                    }
                });

The lets pop that code into a sample app and run it and see what it looks like.

The original Nimbus slider on the bottom and the skinned one on top, both running in the same application. Here is the source so you can try it your self. Let me know if this was useful and what other examples you would like to see.

SliderSkinDemo.java

If you missed our talk and BOF at Java One this year here are the presentations:

Java One 2008 Nimbus Talk PDF

Java One 2008 Nimbus BOF Presentation PDF

A lot of you have been asking about the Nimbus Designer Tool that I demoed at Java One. I have been working at getting it opensourced but it is a slow bureaucratic process so I am sorry. In the mean time I thought I would try and do a couple blogs on how you can skin Nimbus your self with out the tool. It is very easy to do providing you are not worried about getting your hands dirty writing some Java 2D drawing code. You could always use images or a SVG library if you don’t fancy raw Java 2D. I would like to split the designer tool into 2 parts the first part the lets you create a Painter classes with Java 2D drawing code by drawing graphics. The second part would let you assign painters to components and generate the code to populate the UIManager defaults table. But both those parts are not hard to do your self if we help you get started so I will see what I can do.

So just a quick hello to say I am still alive, next to try and post a couple blogs on how to skin Nimbus.

I am planning on submitting a talk on Nimbus and the new Nimbus Designer tool. Covering:

• Using Nimbus L&F in your applications
• Designing for cross-platform, how to design your application to look good on all platforms
• Customizing Nimbus
• Creating new look and feels using the designer tool based on Nimbus
• Creating your own components with Nimbus L&F themeing support
• Designing the look for your own components using the deisgner tool

Might have too much to cover in a hour, don’t want to scare you all off. Any thoughts on what topics you think are the most important/intresting in case I need to cut bits out or anything I didn’t mention here?

• Tabs
• Focus handling is missing from Spinner,Slider, Tree, Table and List
• FileChooser has a lot of issues
• Right to Left for international language support
• 3rd party component theming
• Color theming
• Lots of minor things like table gridlines or setContentAreaFilled() support on buttons
• Exceptions are thrown if the window or some components get too small

Most of these will be fixed in the next EA release or the first beta release. A few of them have been fixed in the last couple weeks, I have just been working on color theming. All colors in Nimbus are derived from a set of UIDefault colors with Hue, Saturation and Brightness offsets. This gives you reasonable control over changing the colors of the Nimbus Look and Feel.

Darker Themed Nimbus

Using Nimbus

There are 3 easy ways to use the Nimbus look and feel:

1. If you query UIManager for a list of available look and feels then Nimbus will show up in the list
2. Add UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel"); to your application before creating any Swing components
3. To specify the L&F from command line, use the following when running your Java application: -Dswing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel

The reason Nimbus is in the sun.swing… package is it is not possible to add new API to the javax.swing… package in a update release. We hope that we can move Nimbus to javax.swing in Java 7 and if it turns out to be popular then we push to make it the default look and feel in 7. Before 6 update N is final we will work out some way for you to be able to use it now and when it is potentially moved without changing any code.

If you Find Bugs

You can search to see if there is an existing at Sun Bug Database or you can view a List of open Nimbus Bugs. You are welcome to post bugs here as comments and I will file them if they are not known bugs.

Other Cool Features of Update N

Improved performance

• The Quick Starter feature will prefetch portions of the JRE into memory, substantially decreasing the average JRE cold start-up time (the time that it takes to launch a Java application for the first time after a fresh reboot of a PC).
• Hardware acceleration support: Java SE 6 Update N introduces a fully hardware accelerated graphics pipeline based on the Microsoft Direct3D 9 API, translating into improved rendering of Swing applications which rely on translucency, gradients, arbitrary transformations, and other more advanced 2D operations.

Enhanced JRE installation experience 

• The Deployment Toolkit takes the guess work out of determining what versions of the JRE end users have installed on their PC. It supplies Java based web applet/application deployers with a simple interface to accomplish Java detection and installation.
• The Kernel installation mode lets first time Java users run applets and Web Start applications without waiting for the whole JRE download. While the default Kernel installation will work with existing Java applets, application developers have the ability to select libraries that should be installed with the kernel, before the rest of the JRE is installed on the end user’s system.
• For current users of Java SE, the JRE update mechanism has also been improved, using a patch-in-place mechanism that translates in a faster and more reliable update process (the patch in place mechanism will take effect for end users who upgrade from this update release or later to a new update release). As an added benefit, follow-on update releases will no longer be listed as separate items in the Windows “Add or Remove Programs” dialog.
• A new Java update download engine provides end users with the convenience of pausing and resuming the JRE download, and relies on a more reliable download mechanism.