So it looks like Sun aren’t going to do any more work to enhance or improve Swing. It’s kind of sad, but not entirely unexpected. I can’t help feeling that multiplatform GUI libraries are a dead end. Depending on what they are doing, what most people want is either a browser interface, or a fully native GUI on their platform of choice. Little differences from what you expect, such as in shortcut keys or menu placements, become annoying rather quickly. Swing never quite got them right, and I’m not convinced any other multiplatform GUI library does, despite the fact that people have been trying to solve this problem for over 15 years. It feels like it’s time to give up on it. I don’t think Flash, AIR, JavaFX or Silverlight is the answer either. A native GUI will always feel better to use than any of these, and a browser interface will always be far easier to manage.



4 Responses to “Multiplatform GUI Libraries Are A Dead End”  

  1. And what is native library? Is it winapi only for windows and X for linux? Every GUI toolkit have it’s own habits. Java have lookandFEEL. While OpenOffice looks under KDE pretty normal – it feels very different. Same for Win32 version of KDE, same for Opera on almost all platforms. Quantity of GUI toolkits is very high our days.
    By the way, Swing let’s you decide do you want to use plain Metal, pretty Nimbus or use platform renderers, nobody else can do it inside one platform. It will not make you FEEL like it is on your platform, but it will look as it is.
    As for me, problem is more platform integration than look. I want Swing to use KDE file chooser, not Swing one. I want Swing to read my KDE keyboard and shortcuts settings. Also I want it to read my icon theme. It is problem of application, not of Swing itself. If I’ll develop something – it will LookAndFeel much like KDE, and Windows users will not like it not because of Swing, but because of KDE-style.

  2. I evaluated different languages for a long time. I agree with you that a native GUI always feels better – but only if you are just using ONE OS! – I use Linux as well as Windows and so I would more appreciate an application that looks the same on both OSes. However Thunderbird or Firefox are good examples on how it can be achieved without Java.

    C(++) is however no real alternative for me. I used C(++) many years ago and was not really satisfied.

    Oh, I didn’t mention all the web out there. We are very far from a common looking GUI on websites. There are completely free and different styles here. Nearly no website looks like native Windows, Linux or MAC. They have their own style. However the look of a web application is mostly the same from whatever OS you are looking at it. And here we are again at Swing. And yes, I am convinced that it makes sense to have a thick client in many cases.

  3. 3 John

    @Aekold: When talking about native libraries, I was thinking Win32 API or WPF for Windows, Carbon or Cocoa for Mac. I don’t have any experience of GUI development on Linux so I’m not sure what the equivalent is. Platform integration and feel are more important to me than look, but my experience is that some people are very sensitive to things not looking “right”. Unless you get *all* of this stuff right, your application will feel “wrong” to a lot of people.

    @Martin Wildam: I thought the same thing when I started using a Mac, but after 18 months of daily swapping between Windows XP and Mac OS X, I’ve decided it’s less confusing if everything on Windows follows Windows conventions and everything on the Mac follows Mac conventions. Java Swing apps are particularly hard on the Mac because they don’t use Mac standard editing key combos (go to start of line, go to end of line, move cursor forward a word, etc.) and I use these a lot.

    Firefox seems better than Thunderbird at following platform conventions. And the browser provides things like editing key combos and print dialogs to web pages, so even though web GUIs look different, at least other things are consistent. Usually at least: but some Ajax pages impose their own keystroke processing, taking us back to square one.

  4. @Martin Wildam: We should categorize main applications you work with. If you are working with NetBeans or Eclipse or Gimp or some big unique tool – it will feel better to be same on all platforms, and may be even look same, so you will not think about platform but about tool. But if you are using text editor or feed reader or file comparator or some other small tool you want to be highly integrated (like to be opened on F4 key or to be asociated with certain file types) it will feel much better if application will follow platform conventions. I am totally agree with John in this case.
    As for me, I want NetBeans to behave its own way on any platform, but I want JEdit to use native file dialogs, read native color scheme, icon theme and font settings, I want it to look and feel like native platform as much as possible, I don’t want to see any difference. It is some priority between platform and tool. It is important for someone to use Firefox and feel it as firefox feels, but for someone it is much more important to open his webpage from here and there, and don’t think alot about what “browser” means.
    And of course “platform-specific” is not always good. There are lots of windows and macos-like Gnome and KDE themes, there are lots of macos-like styles and apps for windows. If you prefer other platform than you had to work with – you will try to make it closer to your favorite platform, including icons, fonts, shortcuts and other feel.
    Returning to Swing – it have all you need to implement it and to switch both look and feel in preferences, but developers of desktop apps just making it their own way, way they like more or just simplest way. It is not swing framework problem, it is human factor. I have some experience with WinAPI, Qt, GTK and much more with SWT and Swing, and I am pretty sure Qt and Swing are the greatest and most flexible tools around. It is metter of your interest and time to adapt it to certain platform, but not problem of framework.