Home > Java > Using Swing’s Pluggable Look and Feel Using Swing’s Pluggable Look and Feel Eugenia Loli 2004-03-02 Java 33 Comments This article discusses the Swing concept of a pluggable look and feel and offers some thoughts on how to use it in a way that is both convenient for the programmer and desirable for the user experience. About The Author Eugenia Loli Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker. Follow me on Twitter @EugeniaLoli 33 Comments 2004-03-02 2:03 am Swing is still UGLY. SWT seems to deal with this issue though. 2004-03-02 2:23 am Don’t get me wrong, you can never have enough techical articles published but this is very old and well documented features. We have also had this discussion numerous times. So what makes this article so special compared to all the pervious post’s about this subject </rant> 2004-03-02 2:30 am You contradict yourself. Swing is fine, as long as the programmer makes the effort to have it look decent. It also outperforms SWT in my experience, but that my be because SWT is only usable on windows (and even then it slows down when lists etc start to get large). I’ve got no issues with Swing. Its more difficult to get it right, but perhaps because it is so easy to knock together a GUI in it there’s tons of half-arsed apps with cluttered event-threads and abysmal performance. But put some effort into it and its fine, as large-scale Office XP clones like Evermore office show. And hell, IDEA or something like that easily outperforms SWT-based Eclipse, in terms of GUI. I think SWT has little technical merit. Its a purely political project, to further IBM’s interests and put pressure on Sun, and little more. Result is that nobody much cares for it but OSS-zealot slashdot teenagers, the sort of people that whinge about open source java, while actual java programmers are out making money and not giving a damn about the whole issue, as they should. SWT is, ultimately, a retrograde step. But no worries, nobody uses it outside Eclipse much anyway. its designed for Eclipse, and only sort-of does its job well, on windows, and therefore only has widgets that Eclipse needs, implemented in such a way that Eclipse needs them. But if you start to make your own apps for it, you realise what a limited widget set it is compared to Swing, and wonder why you are garbage collecting and worrying about dodgy native dependencies again. SWT is AWT++ perhaps, but it doesn’t bring it into the same elague as Swing. 2004-03-02 2:35 am Swing is not ugly. The default Metal look of swing is the ugly one. Personally, I dislike Ocean even more than Metal. If I had the choice, I would make the JGoodies’ Plastic look to be the new default look and feel: http://www.jgoodies.com/freeware/looksdemo/images/looksdemo.png 2004-03-02 2:50 am If you’re using the Windows look and feel, since Swing does not use the native components, what if you have changed the theme in WinXP? Would you then have a Java app that sticks out like a sore thumb ? 2004-03-02 3:28 am Even with Windows look and feel it uses it’s own font rendering, so it will always stand out (especially with ClearType turned on). And you are correct that it is emulating the standard Windows widget set, and it will not recognize and use any themed widgets. Emulating the Windows toolkit leads to lots of “gotchas”, like Swing programs not respecting the Windows setting to resize without redrawing the entire window (until completion). 2004-03-02 3:35 am No, it picks up the theme. There’s a significant improvement in the windows laf when using, say, jEdit when running XP vs 2K. Olive green looks better than silver or blue, IMHO. 2004-03-02 3:36 am At least, the color scheme. 2004-03-02 4:51 am I dont like the complexity of swing, however, the ease of crossplatform development is priceless even if the application doesnt look 100% native. 2004-03-02 6:28 am Why is everyone keep complaining about Swing applications don’t look native enough. Don’t you have better things to do? None of the applications I am using actually look like my native desktop. And some of them are developed by Microsoft. I am using Windows 2000 and both Microsoft Office 2003 and Visual Studio.Net 2003 look different from my native desktop. On top of that, Visual Studio.Net 2003 and Microsoft Office 2003 look different from each other. iTune doesn’t look like my native desktop either. Windows Media Player is also guilty of that. I don’t see people complain about them but of course, people complain about Swing applications do not look native. 2004-03-02 10:21 am Being able to mimic a native look and feel of any OS goes a long ways towards making users feel comfortable with Java. I usually develop Swing UIs that use absolute positioning and as such the user cannot tell the difference between them and the Windows or MacOSX apps they normally use. I’m not a big fan of the Metal or Ocean looks. They look like heavy machinery to me. But Swing is still a better technology than AWT. I could never understand the AWT rationale for going the OS-neutral approach for UI component support rather than do it the way they do now. That decision was a large factor in Java being branded as a server-side technology and it’s hard to play catch-up. All in all though between Swing, SWT and others there are a lot of options for UI developers. Perhaps more so than most OSes (Linux + KDE is king though!) 2004-03-02 10:26 am I am wondering why noone is trying to implement a native PLAF for either gnome or kde, like the one used on OSX? It’s probably a bit complex to get going, but would pay off tremendously in getting java apps integrated into the platform. 2004-03-02 10:36 am I think there is a gtk+ PLAF. I’ve never seen it in action though, so I can’t comment on how it looks. 2004-03-02 12:05 pm The SwingSet2 application that comes with the SDK allows you to switch to the gtk+ LF if you have never seen it. 2004-03-02 2:16 pm knows Swing is crap. Overengineered crap. KISS was thrown out of the window. Every design pattern was used to death. It’s is also inefficient, but that is a direct derivative of point a. Overly crappy designs have that. It also was buggy. If java is not a force to be reckoned with on the desktop side of things, there is a reason. SUN is horrible at doing the desktop side of things. Their most evolved desktop system (Looking Glass) is a crappy ripoff of a 3D user interface M$ research did years ago. One word only: CDE. 2004-03-02 2:30 pm > use absolute positioning and as such the user cannot tell the difference between them and the Windows or MacOSX apps they normally use. (Are you kinda mad? Absolute positioning? What the heck are you actually developing? Dialog boxes?) I think the most obvious difference between Java apps and native ones is the LAF, not the layout. Think FreeType, (supposedly) ClearType, and so on… 2004-03-02 3:11 pm Look no further than the GUI fragmentation. I’m making my first venture into Java for a class project, and it is right horrible trying to figure out which GUI to target. Somebody wise once said a house divided against itself cannot stand, and this Java house lookin’ rather Usher. Wow. Jesus and Poe in one sentence. 2004-03-02 3:31 pm Huh? What do you mean what GUI to target? If you code it in Swing, you can change the look and feel of you application on the fly, and it’ll look like a Windows app on Windows, and OS X app on OS X, and …er… odd on Linux. If you’re talking about GUI APIs like SWT/AWT/Swing, just use Swing. That’s the standard Java GUI API at the moment. 2004-03-02 3:35 pm Windows: I would use SWT. IF, IF I had no desire to do it cross-platform. The thing I do not like about SWT is garbage collection goes out the window. Why use Java if you throw that out? Use .NET instead. Although this opinion might change with 1.5 final in the Summer. It is very fast. I also think look and feel is not that big an issue. Office 2003 kills that. If you get things “close” I think it is cool. If you set a look and feel like Netbeans 3.6 does, I think that is cool as well. For those of you thinking or regurgitating “SWING is slow”, you have not tried the 1.5 beta. You should also look at the JGoodies site to seem some great UI ideas, using SWING. 2004-03-02 3:39 pm .Net isn’t much better. It currently has Windows.Forms, Gtk#, and there will be Longhorn’s Avalon (I think that’s its name) soon^C^C^C^Csome time in the future too. wx.NET is in the works and if Mono becomes more popular we might even see things like Qt# and KDE#. Excuse me, but I don’t see your point. .NET GUI frameworks look like a mess compared to Java… 2004-03-02 3:40 pm If only there was a way of only allowing comments from people that had a remote clue about which they speak. The wonderful freedom of the net. Re java L&F’s, as someone said before me, many apps already don’t share a common look and feel. The issue is not as big as people make it. Besides, Java is cross-platform, it makes sense in my mind that it should have it’s own L&F that is consistent across any platform. 2004-03-02 3:47 pm > many apps already don’t share a common look and feel You mean layout, don’t you? I don’t see how different Java apps can have a different LAF if they don’t reconfigure it themselves. 2004-03-02 3:48 pm “Re java L&F’s, as someone said before me, many apps already don’t share a common look and feel. The issue is not as big as people make it.” Not as big? Really? Is that why people hate java guis, and java on the desktop is dead? “Besides, Java is cross-platform, it makes sense in my mind that it should have it’s own L&F that is consistent across any platform.” Yes, as in “consistently horrible”. QT is also cross platform AND native. A binding to something like QT (or a custome native layer) would be fine. They started doing it with AWT, but, being lame GUI coders, AWT sucked the donkeys balls. So instead of improving it, they created Swing. Which is just as horrible. Puff. Several years later and Java on the desktop is dead. 2004-03-02 4:10 pm The issue really isn’t that big. Sites that are full of whiney underinformed armchair critics like this aren’t representative. Java on the desktop is not dead. Swing is not as ugly as something like, say, Motif. If I have an application that can be run on several different operating systems I’d rather it have the same apperance on each, since it does the same functions. In my mind, that alienates users less. This is a valid point of view, considering it’s Suns default one. 2004-03-02 5:06 pm Qt is not native. It draws its own widgets, much like Swing does. Qt apps on OS X look more out of place than Swing apps which are, for all intents and purposes native. Qt is only ‘native’ on KDE, simply because X doesn’t define a standard widget set, and the widgets in KDE are done in Qt. I haven’t tried Qt on Windows (don’t have $$$ to spare), so I can’t comment on how native Qt looks. Java on the desktop is dead, and it has more to do with Swing’s performance and memory requirements, rather than with its perceived ugliness. The people at JGoodies show that it is possible to make Swing apps look good, and perform well. Sun needs to invest more effort into ensuring that it is easy to write good Swing apps, and not require years of effort to learn. 2004-03-02 5:06 pm So rnu off some big Java desktop apps in widespread desktop usage, by Joe & Jane. Limewire? 2004-03-02 8:31 pm Bob, SWT & garbage collection: only images, colors and a few specific resources are not managed by java. Everything else (99%) *is*. >Why use Java if you throw that out? Use .NET instead. Well, I develop on SWT and my software runs on Windows, Solaris and Linux without a recompile. That means .NET is not an option is it? Hey, I’m not saying SWT doesn’t have it’s share of problems, but it beats the crap out of anything Swing I’ve tried. >For those of you thinking or regurgitating “SWING is >slow”, you have not tried the 1.5 beta. Swing IS slow. Try resizing a swing dialog over another window, move it around a bit on an X-windows terminal… Besides, I don’t use beta software in production environments. The thing is, SWT doesn’t look native, it is native. You see the difference. My 2 eurocents Matt 2004-03-02 10:42 pm “The thing is, SWT doesn’t look native, it is native. You see the difference.” Yeah you do. Even run eclipse on Linux. Blech! As far as .NET I would not “really” recommend that. I am in the Java camp. The point was if Windows was your only target. While SWT does run on the major platforms it is obvious that Windows was its target. Not that I consider that a bad thing. I also have not looked into what SWT3 is bringing to the table. 2004-03-03 1:14 am Swing is complex? Huh? I find it very easy… i’d say Swing’s design is definitely *beautiful*; very OO, very flexible. Love it. Victor. 2004-03-03 5:03 am well at least in my opinion (or preference). after all, winamp doesn’t look n feel like a typical windows app. but i use it what’s more important is that the apps are responsive (good UI/feel) and that the user interface elements are well-thought of. 2004-03-03 7:09 am To me the best option would be to have a default look that looks the same on all platforms like we have now, but also a native look, e.g. the gtk look that applies to all applications using, say swing. This way the user can choose if he wants the app to use the native widget look or a standard look if he wants the same look regardless of platform. I don’t like it if some applications set their own look instead of respecting the users preference. 2004-03-03 3:00 pm “Qt is not native. It draws its own widgets, much like Swing does.” This wasn’t the point. Yes, QT uses emulated widgets too. But the emulation is done at the NATIVE C++ level, using facilities of the underlying graphics mechanism (like X), not in Java using AWTs low-level facilities (point, line, etc…). There’s a huge performance difference. 2004-03-03 3:11 pm Native C++ level? Huh? Emulation is emulation. What facilities does X provide if it isn’t lines, points, text, fills, etc? AWT makes use of native components, so on X, it will be using X’s built in functionality. Of course, if won’t use any of the cool features like DRI (real shame), but it still makes use of the underlying X protocol. Huge performance difference is an exaggeration.