SWT, Swing, or AWT - Which Is Right For You?

An anonymous reader writes "Why is there more than one Java GUI tool kit? The best answer is that one size does not fit all, nor is there a one-size-fits-all GUI tool kit to be invented soon. Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience. Read descriptions of each tool kit's basic features, and the pros and cons of using each."

I like native widgets

I offer apologies for not naming the widget set I like best. Let's just call it UnderConstruction.

Google Cache

Just in case someone actually wants to read TFA:
http://72.14.207.104/search?q=cache:Sdg9JPdYswMJ:w ww.ibm.com/developerworks/opensource/library/os-sw ingswt/+awt+swing+swt+features+opensource+site:www .ibm.com&hl=en&gl=us&ct=clnk&cd=1&lr=lang_en [72.14.207.104]

System.Windows.Forms

I'm lovin' it!

Is none of the above an option?

You don't have to go with those, there are java bindings for everything!> QT, wxWindows, even curses!.

Pick the one you like!

Re:Is none of the above an option?

Yeah, trouble is, no matter which you pick, you'll still be programming from Java.

Re:Is none of the above an option?

You don't have to go with those, there are java bindings for everything!> QT, wxWindows, even curses!.

Pick the one you like!

Pick something besides AWT/Swing, and your users need to download and install it. That lessens the chances that they pick your program, or that they will even be able to pick it - after all, every third-party library needed decreases the chances that all of them have been ported to the target platform.

Thin is IN

The fastest and most furious (and most widely jvm comatible) are thin awt + a few thin third part libraries for complex widgets. Swing is to FAT for my taste!

Why is AWT even an option?

It should be SWT vs Swing. There's hardly a reason to use the plain AWT when there's Swing (a much more powerful library built on top of AWT).

No Win64 SWT

Since SWT is not available on Win64 it is Swing.

My six word summary

SWT : buy
Swing: hold
AWT : sell

Huh?

Why is there more than one Java GUI tool kit? The best answer is that one size does not fit all

That hardly answers the original question -- it's true, but it doesn't answer the statement in question. That would be like saying:

Why is the sky blue? The best answer is that 1 + 1 = 2

The reason why there are three toolkits is simply: originally, Sun developed AWT. AWT was introduced with Java 1.0 as a way to obsfucate the drawing of common GUI widgets on a variety of platforms, using the native widget set. Unfortunately, this was problematic for many platforms, and wasn't very flexible.

Thus, Sun developed Swing. It supported more widgets, and did a lot of its own drawing in order to appear and generally layout the same across different platforms.

Swing, unfortunately, has some design limitations, not the least of which is that it is very memory hungry. When IBM decided to "port" VisualAge for Java from being a Smalltalk-based product over to using Java, they found that Swing wasn't up to the task, so they decided to develop their own widget toolkit, called SWT. SWT wasn't exactly intended for use outside Eclipse, mind you -- it's just that many developers decided to use it as such.

So we're left with a bit of a GUI mess on our hands in the Java world -- one I really wish would be fixed. Swing works, but it can be slow and memory intensive. SWT is non-standard, and requires a platform-specific module which users may not already have installed (which means either you have to tell them to download and install it, or you have to create a bunch of installers for different platforms to allow them to run your SWT-based application).

That is why we have thre different toolkits. For all intents and purposes, the bulk of AWT is deprecated and shouldn't be used for its widgets. It is simply difficult to get rid of due to the number of legacy applications out there which are still using it, and which will probably never be updated to use Swing.

And then there is Cocoa-Java...

Yaz.

Re:Huh?

I don't think it is fair to use the swing memory argument anymore. It is really something that has been worked on.

I agree that there have been improvements, but I'm sorry -- I do think it's fair to continue to take Sun to task for this still.

A quick example -- the jSyncManager [jsyncmanager.org], my most popular OSS application. It can be run in either GUI or console mode. In both, the engine code is identical -- only the user interface differs. Firing it up in GUI mode uses about 35MB of RAM on my Mac OS X 10.4.5 based PowerBook. Firing it up in console mode uses ~15MB of memory.

That's a 20MB difference, and that is just after start-up. The GUI has a single window, with three menus, and a total of 11 menu items. There are NO widgets in the window -- instead it just has a graphic (it's meant to be run minimized -- the menus allow access to help, configuration items, and the log window). And yet that uses 20MB.

Activating every menu item that bring up a GUI dialog once, with the exception of the Help subsystem (which uses JavaHelp) brings it up to ~45MB of memory usage. Bringing up everything including JavaHelp once causes it to use ~55MB of memory. That is 40MB of GUI, and it is all absolutely trivial stuff -- excluding JavaHelp, it's probably less than 50 widgets all together.

True -- I have 1.25GB of RAM in my system, so 40MB is barely even noticed. Still, this is an absolutely trivial GUI (the complexity is in the data synchronization engine -- again, this application is meant to be a "fire-and-forget", run it in the background program which handles PalmOS data synchronization, and doesn't typically require any user input other than configuration).

For a more complex comparison, I fired up "Tapear", a clinical document management system that is part of another Open Source project I work on known as OpenTAPAS [opentapas.org]. It has only one window, but has hundreds of widgets of all types in it, with multiple tabs for a whole variety of different view types. It doesn't have much of anything in terms of an "engine", as it retreives all of its data from a remote database. After loading it up and opening up a single patient, it uses 80MB of RAM -- more than even my entire IDE (Xcode) uses by 25MB.

(I should note that all the above tests were done with the latest release version of Java 1.5 for Mac OS X (PPC)).

One more example -- Limewire 4.9 uses ~75MB of RAM with no transfers.

Sorry, but Swing is still quite memory hungry. Can you imagine running all of your applications as Java applications? Improvements are being made, but I think there is room for further improvements in this regard.

Yaz.

Re:Huh?

I doubt that it really uses 20MB. It just appears to use 20MB. What's almost certainly really happening is that it's mapping 20MB more of virtual memory, of which very little is actually used. For example, if the program needs a class or two from some JAR, the JVM will mmap() the entire JAR file, reserving virtual address space for all of it, even though only the pages that actually get read will be faulted in and consume real RAM. So several megabytes of virtual address space has been "consumed", but only a few KB of actual RAM is used.

I'm quite aware of how to properly profile memory for Java applications, and yes, there is a 20MB difference in actively used memory. The virtual memory claimed is siginificantly higher than what I quoted -- where it's using ~35MB of real memory, the process is claiming a whopping 453MB of virtual memory (which of course isn't allocated at all, and thus doesn't really affect much of anything performance or RAM wise). Opening all four possible dialogs at once bumps that memory usage up to closer to 50MB.

I have a pile of Java memory profiling tools that all agree with this memory usage assessment. Now it's possible that the low level implementation on Mac OS X is more hungry than on some other platforms, but in my testing this is relatively equivalent to running it on Linux and Windows.

Sorry, but Swing is memory hungry. It tends to show in complex applications, which is one reason why I've kept the jSyncManager as simple as possible in terms of GUI.

Yaz.

None of them are very good

I would rather use a web front end than use any one of the three (and I have used them). Java on the client is too cumbersome and support intensive and the majority of users do not like them. Throw a nice dhtml front end at them and they are much happier (at least in my experience).

Right for *YOU*?

Shouldn't the question be "Which is right for your project?"

As this is a typical Slashdot wankathon story....

.... let me post two opposing sides of the swing vs swt debate:

Swt is crap [hacknot.info]

and

Swing is crap [ahmadsoft.org]

Advantages and disadvantages?

Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience.

Having used them, I'm pretty sure that each just has a different set of disadvantages.

Spoiled after 15+ years of [NeXT|Open|GNU]Step/Cocoa, I guess.

None of the above.

Buoy [sourceforge.net] is your friend. It's built on top of Swing, but it's actually sanely usable. I recommend it on the grounds that it is the only Java GUI toolkit I have ever used that did not leave me longing for the sweet embrace of death. Developing an application using Buoy is substantially less painful then stabbing yourself in the eye with a fork. In the world of Java GUI development, this is high praise indeed.

Seriously, though. If you are doing GUI work in Java, but your actual goal is to get something else done, and you would like the GUI toolkit to take less than 80% of your development effort, use Buoy. It's not "dumbed down"; it's just SANE.

For the indecisive, SwingWT

Although in beta, the pure java LGPL'd SwingWT http://swingwt.sourceforge.net/ [sourceforge.net] attempts to replicate the Swing API (and it's huge) using SWT code. You distribute your platform specific swt library with your build, make sure it's in the searchable path (./binlib for example) and you're good to go. The AWT api is replicated as well.

So even IBM can't handle the slashdotting...

Our apologies The IBM developerWorks Web site is currently under maintenance. Please try again later. Thank you.

IBM slashdotted!

Our apologies

The IBM developerWorks Web site is currently under maintenance.
Please try again later.

Thank you.

Hehe.

Swing

I've never used SWT, but I have quite extensive experience in both AWT and Swing, as well as many other GUI toolkits, including two cross platform toolkits of my own for a commercial product that shall be anonymous in this post.

In my opinion the Cocoa AppKit on OS X is perhaps the most elegant overall. The problem is that with Cocoa AppKit, the common things are extremely simple and easy to do, but the more uncommon things can be quite tricky. With Swing, the most common things are still simple, but take considerably more code than with Cocoa. But when you get to something more advanced where you want to get some custom behavior (maybe dealing with drag & drop on some custom widget, or perhaps you want to customize the selection model on a tree widget or somethign similar), then Swing suddenly becomes much easier to work with compared to the otherwise simple Cocoa.

AWT isn't really an option over Swing in my opinion. It's there for historical reasons, and as the low-level API for Swing. Swing is built on top of AWT, after all.

There are a couple of larger problems with Swing:

1) Performance can suck if you don't know exactly what you're doing.
2) Making it behave exactly like you want often requires you to know it quite well.
3) It is quite large and complex, and can seem overwhelming to learn.

The performance problem is actually the biggest reason Java is still perceived as being slow by many people who aren't familiar with it. Developers often shoot themselves in the foot with threading issues, and it makes Swing UI's seem slow and poorly responsive. Also, because of poor understanding of the more advanced layout managers, it's also not uncommon to see Swing based UI's that just... look sort-of wrong. They don't look like native apps. Not because of look & feel issues of the widgets, but because of margins and paddings around widgets being wrong. You have problems like buttons being too large, text areas being right up to the edge of the window, quick-hack looking layout of widgets in preferences-style windows that have a large number of widgets, and so on. You often also see things like the app not painting itself during window resize drags, default window icons, inconsistent font sizes, and so on. Many of these are simply caused by people not fully knowing the Swing API and not knowing how to do things properly. It's not that you can't do them right, it's that people don't know the tool thoroughly. In my opinion, this is directly caused by the API being overwhelmingly large for many developers. While it gives Swing its incredible flexibility, it also indirectly is the cause for many of its problems.

Sun is tackling the performance problem from one end. They are working on accelerating a lot of the lower level graphics API (image drawing, primitive drawing, etc.) with OpenGL and DirectX. This helps a lot in many situations, but it doesn't help in the cases where people do 3 second tasks in a UI event callback method. Likewise, the ugly-UI problem is being helped by better IDE's (Matisse in Netbeans 5, for example) and by Java SE 6's (Mustang) better handling of system look and feels.

Still, there's a long way to go. But Swing is getting better every day, and it's the standard choice that works on all platforms, and it IS possible to do excellent UI's with it even today. You just need to learn it well. My recommendation is to read the API reference until you know it by heart. Then study the Swing source code to see how things work under the hood.

From a Technical POV...

In SWT it is easy to make plugins, because the components can and do get GC'ed after you properly dispose() of them. In Swing, many components are immortal, i.e. (J)Dialogs and (J)Frames are particularly stubborn. They are kept in some AWT Vector's inside the innermost painting loop and never die (hint: Sun, what about using WeakReference-s where appropriate? I know, not always possible, may break apps, etc.). On the other hand, if you forget to dispose() some SWT component, you end up with lots of leaks in your app. If you want plugins, learn resource management, and use SWT. You can go with Swing as well, but be prepared to require a restarts when a plugin is updated, only you will have to make the classloading on your own. If you want to write portable, static GUIs for Java, Swing is the way to go, as it is much, much easier to use.

Swing is maturing, SWT has growing pains

I give much credit to SWT for putting a fire under swing and forcing them to improve. The current Swing is much better then it was a few years ago. It can take some long years before a toolkit matures and best practices for its use come out. I feel like that is happening now with Swing. If some of the SwingLabs stuff gets put into the real pipe that would be lovely.

SWT seems to be encountering some growing pains as it really starts to cover everything that a toolkit must. I wish them luck in pulling through even stronger (on all platforms please). SWT certainly has had a strong start.

It seems like there are enough Java developers out there to support 2 GUI toolkits. I think in the long run this can only be good for Java as a whole. If people don't like one they can stick with Java and swap out the toolkit. If one eventually becomes "the one" then it will only be because the other pushed it to be the best it could.

SWT if Sun would adopt it

JFC is a fine class library but it is horribly, horribly slow, and not even the latest versions pick up the native look & feel properly. Of course JFC is a nice API so that counts for it, as does the fact that installs by default, as do the abundance of tools. But SWT uses native widgets for its rendering so its considerably faster and more integrated with the environment. If both shipped in the same box, I'd pick SWT. As they're not, I'm reluctantly stuck with JFC.

AWT is a waste of time. It's just too antiquated.

SWT vs Swing - no clear winner

I can't read the article but IMHO there is no clear winner in the SWT vs Swing debate (AWT died years ago).

Swing is slower and not quite native, but comes with every Java VM (or the important ones anyway) and is very flexible.

SWT is fast and more native, but requires external machine-specific JARs which can be a pain to deploy, and has a more limited design.

In Java I tend to use Swing because I am making applets, so the deployment issues are important to me. If I was going to create a large-scale application like Eclipse I would be tempted to use SWT, since the installer could handled the SWT specific issues.

Java programmers really should not be complaining about having two first-class GUI APIs.

Question

This may be a dumb question, but why can't Java just provide access to the existing desktop GUI (Windows, OSX, QT, whatever) rather than re-inventing the wheel with it's own set of widgets that inevitably don't look or behave like native apps?

Re:Question

You can use Java with GTK, Cocoa, or native Windows toolkits. The question then becomes, why Java programmers are not interested.

The basic reason for this is, your application's GUI becomes completely unportable, and you suddenly have little reason for having written it in Java in the first place instead of the platform's "standard" language (C, Objective C, or C#).

A "middle way" is to do what SWT does and wrap the native widgets with a generic API. This creates a "lowest common denominator" problem, however, since you inevitably have to stick to only using those widgets which all your target platforms have...

AJAX

The correct answer is, "None of the Above."

Before you invest a lot of time, effort and money crafting a GUI front-end for your application, you should really stop and consider that you may not need one.

If your app is basically a way of querying a database on a server deep in the bowels of the computer room, you should be coding the interface as a web application. Especially now that AJAX is on the scene... modern AJAX tools and a Java backend can put together some very powerful applications that don't have the same development and deployment costs that an executable on every desktop would.

AJAX isn't a cure-all, and not likely to help much if you're interacting with local datasets with lots of processing horsepower (as in an imaging program like the Gimp or a sound editing program) or constructing a platform-independant application that's mostly self-contained (like a game or a p2p client.)

It is great for things like CRM applications, scheduling tools, inventory tools and ticket-monitoring... stuff that need to read and set values in a database somewhere. It's even good for applications that were previously in the domain of the workstation and the PC, like lightweight data visualization tools and PIMs.

What's more, the development cycle of an application that only needs a copy of IE or Firefox to run will be a lot easier for you, the user/customer and the poor slobs in IT who would need to come up with a deployment plan, and =then= an upgrade plan when rev 1.2 comes out.

SoupIsGood Food

Customer choices.

As a rule of thumb, the most important issue is multiple JRE/JVM management. If you have any issues with this, use SWT as it is not JVM/JRE dependent. On the other hand, SWT's got it's own set of problems...

Here is some of the issues involved.

Swing versions are JVM/JRE version dependent. You really need to ship a JRE with your app and make sure it is used.

In the real worlds, thats not always possible. Customer policies may prevent user control of the JVM's available.

Even when you can specify the JVM's available on client machines, you cannot always guarantee that the particular one that will be used with your application, or worse yet, that someone won't put in an upgrade to the JVM that breaks everything.

It is not uncommon to patch the JVM for specific fixes like memory leaks. You have no idea whether or not the JVM/JRE you are running on is vanilla or not.

Of course, there are lots of other issues involved with using SWT, mostly due to it's immaturity. Don't try real serious OPENGL stuff unless you wanna do a lot of debugging.

And don't even get me started on embedding Windows apps in SWT programs. It can be done, but, in my experience at least, bug detection requires a Russian Roulette approach unless you write your own code. Some things work, work partially or work for a while and then trash some OTHER program.

One interesting suggestion:
If you can pull it off, write your GUI code is some stable environment like VS.NET and call functionality in Java via web services or other remoting technologies.

The talent pool for skilled GUI developers is a lot larger.

Swing is never finished.

Swing has improved over the years, but it has improved at an unacceptable pace.

Call me back when it finally supports Clear Type.

Cheers,
Adolfo

Book

There's quite a few books on choosing frameworks, here's one [amazon.co.uk].

Windows Forms!

A big developer complaint with Linux is that there are so many GUI toolkits to choose from, they all look different, and have different APIs. With Windows it's different: one standard API, one look and feel. Business developers like that. Java, with its proliferation of different, different-looking GUI toolkits, is suffering from the Linux problem. That makes it less attractive as a deployment platform for real-world applications. For most applications which will be delivered to Windows desktops, the best choice is to use Windows Forms on .NET.

And don't say web apps. Web apps suck. Their UIs do not scale up to the heavy-duty data entry people do in a corporate environment; they tend to require too much mousing around. Browser Web form usability just isn't up to the standard established by GUI apps, particularly when it comes to keyboard navigation.

Most typical client apps

Today if you are not building it for the web you are just plain wrong. Now granted there are a few apps that will not fit the web model but no many.

Bongo.

The best Java widget set I ever used was Marimba's Bongo, back in '97 or so. It was fast, lightweight, extensible, and even included its own sweet VB-like interface editor. Like so many other great early Java libraries (remember JGL, anyone?) it was killed by Sun's insistence that they were about to ship their own widget set with java, which pretty much put the kibosh on third-party widget set development. Two years later, we finally got... swing. Which is just one of the reasons I haven't written a line of Java code in over four years. -p

A fourth option: SwingWT

As the article mentioned, Swing is a very good, advanced toolkit with some advantages over SWT. A project called SwingWT is an implementation of Swing using SWT, giving you a much faster GUI that looks and feels more native. So you can do all your development and initial testing with pure Swing, then swich the UI classes to SwingWT for a native look and feel on the hosts that support SWT. Seems like an interesting idea to me.

The end-user doesn't care about the API

Swing is ugly, period. Why? Because it does not follow user's preferences and standard look&feel. Most of the previous posts seem to assume that the API is important. It is not. What is important is whether the user will like using your application or not. And, sorry, but most of the users are on Windows, and there is a standard look&feel Swing does not follow. Therefore, the users won't use your Swing application. Ever wondered why Java had so much trouble breaking through on the client side?

If you remember that most of the applications don't have to be run on all platforms, but only on some specific ones (Windows, MacOS), and that most of these applications won't need to be run from a webserver (common! my mother won't install a webserver just to use Excell nor to start her tax computing tool!), you only have the choice between .Net and SWT. Why? Because both are able to display a transparent red scrollbar if the user decided that all scrollbars should display that way. I want my Windows users to start a Windows application, not a Java application. I want my MacOS users to start a Mac application, not a Java application. They don't care about Swing or SWT, they really don't! But they want their nice-looking transparent red scroolbars!

Swing is a nice toolkit when you code software for other coders, or when your target audience is running Linux. For the remaining...

Too many freakin' guis

This is the trouble with Java.. there are too many GUI libraries. Standardize on one and forget the rest. It seems that when an environment is born without one, it's destined to search for the perfect gui framework forever.

As an example of an evironment which has never had this problem, take Mac OS X, it has had AppKit since the day it was created... and it will never see another major gui framework. Ah, yes... you can say but there's GTK and others available on the Mac, but they are not a threat to the *MAIN* AppKit framework... (they do, in fact use AppKit, so they aren't an outright replacement).

Intersting dilemma...

But... to get back on topic, I prefer SWT, it's faster, and it blends more readily with the native environment than the others.

GJC

behind the times

"Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience."

That should say some are missing features and some have bugs.

I mean give me a break, haven't all the other companies moved on? Sun can't even get a 2D gui control toolkit together and it's 2006. This should have been one of the first things they did.

Did they really want to keep having ugly, weird working scrollbars, no-colour, no style interfaces unless the programmer spends as much time on the gui as the rest of the program? If yes then success is at hand.

Personally I would just raise the bar and consolidate.

Sun, question to you: how long did it take to figure out that you restrict programmers on the use of the if statement? I'm sure you and several 3rd parties could have had a thousand if packages, IMAGINE THE CHOICE!!! You would have ruled my friend!

Stuck in the past, stuck in the past. I don't see other mature companies still wrestling with evolution on 2D gui toolkits. You're still in the playground on that.

"The nice thing about standards is that you get to choose from so many." Should be your motto.

whatever

Why are java applications so ugly?

I cannot think of a java application that I have used that has not been ugly. The UI people often do not make the best programmers and the programmers often suck at designing good UI. And, WHY THE FUCK CANT YOU COMPILE JAVA INTO AN EXE?

Swing!

I like Swing, mainly because it can be easily extended to do things with components they were not originally designed for. You can fairly rapidly build a relatively complicated user interface, with custom components, custom events, and multiple interacting display windows, and still have perfectly manageable, re-usable code. (Well, if you work outside graphical designers, which in my humble opinion should only be used for developing write-only code.)

I agree that it can take an effort to master it, and that developing simple interfaces can take extra time because of the overhead. But Swing's structure is quite ordered and I have found that Swing suits "my" logic; it comes fairly natural to me as a programmer.

I like Swing much more than AWT, which IMHO was not very good at all, mainly because the event handling model was awful. For me the biggest problems with early versions of Swing were in the use of images, and while the image handling libraries are much more powerful and rationally organized now, they are also unpleasantly complex. But it is good enough. I have never tried SWT.

Web interfaces are nice for many applications, but for most of the things I do not really an option. For database applications a pretty good middle way seems to be Java Web Start, which allows you to use a web server to distribute your code, but still to run it as a very flexible application on your desktop.

In summary

AWT: old, based on OS controls but didn't do a brilliant job of doing it cross platform. Age means its the best choice for portability (e.g. it will run on both the MSJVM shipped with many versions of windows and virtually every sun jvm)

SWING: built on some of the very basic awt classes (container window frame and applet) with a widget set written in 100% pure java, consistant behaviour accross operating systems but even if you choose the platform look and feel its still a clone and there are liable to be subtule differences between your app and native apps. Also has a reputation for being slow (which was undoubtablly true with some versions though i belive this has improved) can run with things like the msjvm provided you are prepared to put up with downloading the swing classes.

SWT: also based on the native gui components but didn't try to be quite as deep an abstraction so will generally run faster and be more familiar to those used to writing native code. However as a third party library using its own native code it cannot be used for stuff like browser applets or java web start.

AWT is crap, Swing is heavy and slow, SWT is...

AWT is totally crap; it lacks much functionality of modern GUIs.

Swing is heavy; it implements its own window system, complete with event queues and region management. For those that don't know what regions are, they are display lists of visible rectangles. Clipping works by subtracting a region from another region, i.e. subtracting one list of rectangles from another list of rectangles. This means two things: a) crazy memory requirements, as each operation produces a new rect, b) slowness in order to compare all rectangles with each other.

SWT seems the better option, but I have no idea, even after reading the article, if it is totally portable and extensible from Java.

Missing option

Which one? I don't use any of them: Java is bloated crap.

Pretty good if a little misleading

Personally, I generally avoid using AWT directly -- but it supports many things that you marked as "N/A". For example:

Display an image -> java.awt.image.BufferedImage
Display text and image -> java.awt.image.BufferedImage
Generic container of other controls with a border and title -> java.awt.Frame
Add items to the system tray -> java.awt.SystemTray
etc etc

Also, while you do comment on the fact that SWT doesn't come with the JDK, you say "If you are developing only for one platform, SWT has an advantage in host compatibility"... that's not quite accurate... IBM has been notoriously behind on JDK implementations (ie: how long until it supports the JDK1.6 features?). The SWT FAQ says that it is built on JDK1.4, so it is already 2 major versions (a few years) out of date. Also, their download page ( http://download.eclipse.org/eclipse/downloads/drop s/R-3.1.2-200601181600/index.php#swt [eclipse.org] ) doesn't even show my server platform (FreeBSD) on the list...

Personally, if the library requires a native download, I'm not using it -- too much hassle to maintain.

uhg...

GridBagLayout

*wretch*

Re:Ugh

Only when they make a deodorant by the name of "Conceptually Oxymooronic" I'd consider using some.

Re:Ugh

What about roll-on? You insensitive clod!

Re:Ugh

To paraphrase Tesla :

If you thought a bit more, you wouldn't have to sweat so much.

Deoderants are for the dirty +)

Re:Bussinessmodel?

At least if someone gives you an open source poo, you can demand a copy of the food they ate to produce it.

Right, or vi versus emacs

Since the answer is obvious... the preferred depends on the task at hand. 7337 h4x0r5 use both.

Re:SWT AWT Swing

But I have a GTK look and feel now Sincerly, SWING