It seemed like it was time to close the polls, I don’t think there is a clear answer across all platforms. On windows there is a clear winner for the native look and that makes sense as Windows LAF has had a huge amount of work put into it over that last 5 years plus. If there was the resources to put a equal effort into the GTK LAF and a new KDE LAF then they would be clear winners to. Nimbus is a great cross platform look and feel and allows people to create good looking applications but maybe is not the simplest look and feel for people to start with as it takes a little effort to make a great looking application with it. Also it is not the best for compatibility with applications written to work with other look and feels so is a dangerous choice as a default. So I kind of feel that we could go native on Windows and people will be happy but there is no clear answer for GTK and KDE. I will pass the poll results on to the other people who have a say in the decision and see what the consensus is.
Posted on May 12, 2009
Posted on Mar 25, 2009
After watching the voting and reading the comments I have noticed two things: First is from 30 votes to 800 votes the percentages have hardly changed which means we seem to be falling on a conclusion. Native LAF has varied from 59% to 63% so nothing major and is a clear winner.
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
What should be default LAF for Windows?
- Native (Windows Look and Feel) (63%, 577 Votes)
- Nimbus (34%, 310 Votes)
- Ocean(Metal) (3%, 22 Votes)
Total Voters: 909
What should be default LAF for GTK(Unix)?
- Native (GTK Look and Feel) (51%, 411 Votes)
- Nimbus (45%, 359 Votes)
- Ocean(Metal) (4%, 32 Votes)
Total Voters: 802
What should be default LAF for KDE(Unix)?
- Nimbus (63%, 493 Votes)
- GTK Look and Feel (31%, 241 Votes)
- Ocean(Metal) (6%, 44 Votes)
Total Voters: 778
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.
Posted on Mar 16, 2009
The other day I was discussing with colleagues if Nimbus should be the default LAF(Look and Feel) for Swing application. The current default LAF is Ocean which is a spiced up theme for Metal which has been the Swing default LAF since the beginning. It feels like with a large release like Java 7 it is about time we changed the default LAF to a more sensible choice which leaves two choices Nimbus which is the new cross platform LAF and the system native LAF which will be Windows LAF on Windows and GTK LAF on Unix. Apple has already gone with the system native choice and the default LAF for Java Swing applications on Mac is Apple’s Aqua native LAF. The only reason for remaining with Ocean LAF is to maintain backwards compatibility for old Java applications which were written with static pixel based layout so will be all messed up if the size of components changes. My feeling is that sector of users should be getting pretty small now and as long as we provide a easy work around like system property file that lets a user/administrator change the default LAF back to Ocean for those few special cases then we can move forward and select a modern LAF as the default. So then it comes down to what to choose Nimbus or Native(Windows/GTK) I am torn between the two. So we decided the best idea is to ask more people, so what do you think?
What Swing Look and Feel should be the default in Java 7?
- Native (ie. Windows LAF on Windows, GTK on Unix) (56%, 465 Votes)
- Nimbus (40%, 330 Votes)
- Stick with Ocean(Metal) (4%, 34 Votes)
Total Voters: 829
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.
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.
Posted on Jan 14, 2009
I am just reviewing the submissions for JavaOne 2009 and was looking back at what we did for JavaOne 2008 and noticed Sun has posted the slides with audio from our session on Nimbus last year. So if you are interested in Nimbus and were not fortunate enough to be able to come and see us in person or have listened to it already. Then it is well worth checking out as I think we made a good attempt to explain how Nimbus works and how to use it.
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.
Posted on Aug 27, 2008
Nimbus is completely configured by properties in the UIManager defaults table. In my last blog I showed a simple example of how to skin a single component. This gave you a sneak peek into the power of these properties. Lots of people have asked for a complete list of properties that can be set, well its simple just grab
UIManager.getLookAndFeelDefaults() and iterate over the contents of the map and print the keys and values and there you go. Well I am not that cruel so I did the work for you and will include a link to a complete table of them at the end. But before I get to that let me explain how they work.
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.
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
/** * 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.
If you would like to see how I made this list, here is the code that creates the html.