Linked by Andy Roberts on Thu 19th May 2005 19:33 UTC
Java Swing comes with "pluggable look-and-feel technology", which essentially boils down to the fact that interfaces can be "skinned" (although this is simplifying a tad) and is therefore, extremely flexible. By default, Java ships with a cross-platform look-and-feel (LAF), which means your apps can look consistent across all platforms, or LAFs that mimic the look of a specific platform, say Windows, for example. However, one of the chief complaints of Java desktop applications is its "look". It basically stems from two issues:
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Java did go down the route of native widgets, which can be seen in the AWT package. The problem was that it only came with basic widgets and not many devs enjoyed using them.
SWT is Java toolkit that uses native widgets. Except it does and it doesn't. In their quest to provide a consistant API across all supported platforms, they came into difficulties, and in effect, they have to play to the lowest common denominator. Say platorm A, B, C and D allows feature X, but platform E doesn't, then feature X has to go, at the disadvantage of the other platforms. There are even widgets that SWT emulates for certain platforms as they simply don't exist. As a programmer, if you are aiming to support multi-platforms this way, you need to become aware of the little intricacies of them, e.g., [from the SWT page]:
"For example, programatically giving focus to a "radio" button on Windows will cause it to be selected. Period. Since it would be exceedingly difficult (and is counter to the Windows user-interface look and feel) to prevent this behavior, the Windows version of SWT generates events as if the user had "clicked" the radio button when it is given focus. This means that well-written applications can ignore the differences, but also means that smart developers will test SWT applications on every platform which they are to be delivered on."
The Swing approach was designed as an emulation layer, if you like. This means they can provide each platform the same set of rich widgets, and they can potentially program them to look and act native. An advantage (to some perhaps) is that Swing provides a consistant look across all platforms - something the native toolkits can't achieve. The advantage for me as a developer is that I can deploy only one version of my app for all platforms, whereas those using native widgets have to release separate ones for each of the target platforms.