Malcolm Davis's Blog

NetBeans, look & feel comments

Based on comments from my blog NetBeans 3.6, I downloaded and installed the beta of NetBeans 4.0. NetBeans shows major signs of improvement in many categories (performances, memory footprint, app layout, features). Sun's effort will make NetBeans enthusiast happy. However, it also demonstrates a major issue.

Working in multiple environments, dozens of tools, the sense that there is a 'native look & feel' escapes many developers. Possibly because many programmers care more about developing object interfaces than user interfaces.

When I first started development during the O/S 2.0 & Windows 3.0 days, consistent 'look & feel' was a huge issue. It was an important detail that app keys have specific mappings (such as F1 for help), and commonly used functionality was in the same location (such as opening a document). Eventually, even toolbars had the same images, and common dialogs appeared. The mindset is similar to 'coding standards', users shouldn't have to re-tool their head each time they start a new application. Additionally, all that was required by developers was to follow the published guidelines. [Yes, the standards are published. I first read the UI guidelines for O/S 2 development in the late 80's.]

The NetBeans guidelines can be found at http://ui.netbeans.org/docs/nbui_styleguide/style_guide.html

Java Look and Feel can be found at http://java.sun.com/products/jlf/ed2/book/

The promise of native look and feel was promoted by Sun via Swing. "A Java application running on the Mac can have the Mac look and feel, the same one running on Microsoft Windows can use its look and feel, and that same program running on UNIX can use a UNIX look and feel." - James A. Gosling http://java.sun.com/products/jlf/ed2/book/HIG.Foreword.html

Wow! What a concept. However, I haven't seen the promise of "native look and feel" realized through Swing, NetBeans or Sun.

Each major IDE has pros-cons. I'm not disputing that NetBeans contains things that are missing from Eclipse, and NetBeans does several thing better than Eclipse. However, Gosling and friends slammed IBM's SWT during JavaOne fireside chat. SWT does give the 'native look & feel" that the end-user expect, the same end-users for whom I'm developing applications. Sun should provide a great alternative to SWT, and demonstrate that alternative in a product.

Comments

• If you care for native rendering
  Then vote for this RFE at the bugparade, which asks for Sun to implement subpixel antialiased font rendering in Java: BugParade. It's currently ranked as number 11, but with a few more votres, it can go into the top ten RFEs.

  Posted by: iampivot on August 19, 2004 at 01:54 AM

• More detail
  Could you perhaps give some examples of what annoys you most?

  Posted by: dynamite on August 19, 2004 at 05:31 AM

• Eclipse L&F...
  I am using Eclipse Version: 3.0.0. at work...but you can be sure that it doesn't have a native look&feel....(almost by default).

  Posted by: kadrianus on August 19, 2004 at 06:31 AM

• Eclipse L&F...
  Exactly, it's even worse than NetBeans (IMHO).

  Posted by: pbackx on August 19, 2004 at 06:45 AM

• native look and feel not a big deal
  I personally don't feel that "perfect" native look and feel is a big deal, and I'll bet most non-developers would agree. If the program looks nice, has a well-designed and thoughtful GUI interface that makes the workflow clear and simple, and just plain works, then I don't particularly care if some widget is off a few pixels or doesn't "skin" well. Every app has it's own personality anyway, and many "native" windows apps I've seen lately don't look native at all -- just flashy sculpted look or web-browser look.

  I admit that it drives some people bananas if everyhing on their desktop doesn't look exactly the same, but I think that's a small population. Sure it's nice to have, but it's really not a must have.

  I'll 2nd the other poster who said Eclipse 3 doesn't look "native". It seems to have more features than NB 4, but it shows in that the interface is cluttered and "busy", whereas NB 4 seems much cleaner. But I couldn't give a rip whether either one is native or not as long as it's easy to figure out how to do my work and not hard on the eyes.

  As I implied, it's just my opinion. Your mileage may vary.

  Posted by: gerryg on August 19, 2004 at 08:24 AM

• It's the feel, not the look
  I like different look and feels. I like being able to add an artistic flavour to my desktop. It's the same thing to me as hanging a new picture, or updating/freshening the look of my surroundings - be it my workplace or my home.

  So having the look remain exactly the same pixel for pixel year after year isn't the most important thing to me. What needs to be consistent is the feel. If I use a Java app or a native app, CTRL-C should behave the same way. Double-clicking a table cell should behave the same way. What's with triple-clicking in Java anyway?
  What's with clicking in a JTextField and having the cursor default to the first column instead of where you clicked?
  etc...

  It's easy to adjust for a refreshed look, but painful to adjust for a different feel.

  Cheers.
  

  Posted by: markswanson on August 19, 2004 at 08:49 AM

• Eclipse L&F...
  Are you implying that Netbeans has a look and feel more like the native platform than Eclipse? This is probably the most asinine thing I've read in a while.

  Everytime I've shown a Swing application to a non-programmer, I always get asked why it looks funny. I've also seen programmers and non-programmers say that a well written Swing application responds slowly. They see the Swing UI and automatically think that because it's Java it must be slow even though the application in reality is very responsive and performs well.

  While at a local college, I was demoing some software to some CS students. I was using Java Web Start to launch my SWT based application. After showing the software I received a number of comments from students saying that they expected to "see some clunky Java application" after seeing the Java Web Start spash screen. They then proceeded to ask me how I was able to launch a native application through Java Web Start. They were all very impressed when I explained to them how SWT works. They were also very impressed when I showed them that my Java application was faster than a C++ application that performed a very similar function.

  It's time for Sun to fess up to the fact that end users don't like the look and feel of Swing. Sure it's a powerful framework but end users expect a native look and feel and Swing doesn't deliver that. SWT DOES deliver that nicely.

  This is not an issue of which IDE is better, Eclipse or Netbeans. I can write Swing apps in both and I can write SWT apps in both. The fact of the matter is that the people who actually like to use Swing applications are few and far between.
  

  Posted by: heathm on August 19, 2004 at 09:29 AM

• I disagree
  I would have to disagree with you regarding Swing. While I personally feel that SWT is a dead-end, Swing definitely has a lot of life left in it.

  There are a lot of Swing applications out there and the end users do not even know that they are Java let alone Swing. Over half of the applications I use on a daily basis are written using Swing. These do not include my development tools which are all Swing tools.

  The problem that Swing faces is that it is hard to code. It is a lot harder to code than VB and other Microsoft technologies. Personally I think this is a good thing but a lot of developers produce garbage Swing code because of it. Then they blame the API for being slow. I have yet to find a Swing application that performs badly but was well written. In every case that I have looked into a poorly running Swing application I have found code that makes me want to cry. Is this the fault of the API? I don't believe so. Rather I feel it is the fault of programmers who have either become lazy or were lazy to start with.

  While I lot of people feel that IDE's are a great boon to programmers, I feel that it is the IDEs with their "drag and draw" GUI interfaces that cause the laziness. If these same programmers would take the time to learn how to code Swing apps the way they were meant to be coded, we would see a lot more applications that perform well.

  As for the main topic, I do feel that the Netbeans team need to come back to the native look and feel. While it is not horrible on Windows, it is atrocious on Mac OSX. It is a shame too, since I used to use Netbeans until I switched to OS X.

  Posted by: mzarra on August 19, 2004 at 10:24 AM

• Eclipse L&F...
  I've used Eclipse on my OS X box, and I have to say, it is as far away from native L&F as some Swing apps are. I have no idea why people keep saying SWT gives better native L&F as compared to Swing. Simply not true. Besides, everyone knows that unless you are using Windows, you are a second class citizen when it comes to SWT no matter how much IBM and it's consortium explains that is not the case.

  Posted by: sleepy on August 19, 2004 at 11:25 AM

• Eclipse L&F...
  SWT can give you a perfect native look and fel, because the widgets you are getting are native widgets. Eclipse itself, which uses SWT, admittedly wanted to have a distinctive look and feel, and they did just that. However, none of those things that make Eclipse look non-native are in the "core" of SWT - it is layered on top of SWT.

  Posted by: kenlars99 on August 19, 2004 at 11:56 AM

• Eclipse L&F...
  If SWT (or Swing) doesn't feel that native in Mac OS X, that's mostly because there is a lot of UI guidelines the application has to conform to to get the Mac OS X feel. This is not a shortcoming of the windowing toolkits like SWT or Swing but of the application, though using Cocoa as the toolkit would make conforming to those guidelines easier. It's things like the order of dialog buttons and center balanced layout you need to worry about. The fact is, Mac OS X sets a high bar on user interface design of applications and even native Cocoa/Carbon applications can fail to make it.

  
  Of course, SWT is native Carbon anyway, so it's as native as it gets from a pure technical point. The Eclipse "look" you see in 3.0 has just the view/editor tabs and the view borders differently than native OS counterparts. This actually has not changed compared to Eclipse 2.1, but just became more pronounced. Considering that native windowing toolkits don't have a concept of a whole bunch of views and editors all contributed through individual plugins sharing a window, it's reasonable for Eclipse to try and provide that "workbench" look.
  

  Posted by: cagatayk on August 19, 2004 at 03:33 PM

• I disagree
  I think you've hit the real issue here, but I disagree with your conclusion.

  I agree that good swing code can look, feel, and perform as well as native code (for all practical purposes). However, I think the abundance of bad swing code IS the API's fault. The API is poorly designed. It's too easy to find yourself doing processing in the AWT event loop that doesn't belong there. It's too difficult to figure out how to block mouse events when doing processing that musn't be interrupted (glasspane? gimme a break!).

  I went to all the java desktop talks at javaone this year, and many of them were filled with advice on hacks and workarounds to get swing to do stuff that we all want to do in an easy, consistent way.

  Rich

  Posted by: rich_unger on August 19, 2004 at 05:11 PM

• It's the feel, not the look
  That is spot on. I had no problem with the new Windows XP 'look' because the 'feel' was exactly the same.

  Lack of native feel elements
  Here are some of the native Windows 'feel elements' that are missing from Swing:
  1. ClearType (Microsoft's antialiasing of fonts)
  2. Typing the name of an element in a list or table will select that element.
  3. Pressing the Enter key selects the currently armed button, not the default button. (How many Swing users have had the painful experience of choosing 'OK' instead of 'Cancel' because they expected this?!!)
  4. Ctrl-backspace in a text field deletes the whole word
  5. A heap of options appear when you right-click on a file in the Open File dialog.

  Anyone who uses any of the above features (or numerous other little Windows time-savers) will quickly find that Swing is lacking. Maybe not enough to replace it with an alternative native app, but enough to leave a bad taste in his or her mouth.

  Poor API
  That bad tast is made worse because it is far more common for Swing apps to be buggy and slow. I think this is a function of the poor Swing API and implementation. Some very common things are either harder than they should be (e.g. adding a scroll bar to tables should be automatic) or next-to-impossible (e.g. disabling all input while performing a long operation - glass pane doesn't disable key or window-close events!).

  The solution?
  The slowness of Swing is no longer an issue, but the other two major deficiencies remain. Maybe one day Swing will simplify the API to make programming easy, and have copied enough feel elements from Windows to allow me to use it just a quickly. Until then I'm supporting SWT.

  
  

  Posted by: marc_ on August 20, 2004 at 08:11 AM

This work is licensed under a Creative Commons License.