Rob Warner

Yes--look at the TableEditor class.

My comment dealt more with the traction that Swing has. Many developers know Swing, and feel no compulsion to switch. Sun is behind Swing. These reasons alone, I believe, will keep Swing around.

As far as Swing advantages, I see a couple:

1) Swing is written and maintained as a general purpose widget kit; SWT is written and maintained as a widget kit for building Eclipse. SWT is still terrific for building general purpose applications, much of its development depends on Eclipse needs (i.e. "That isn't a priority, as Eclipse doesn't need that").

2) Third party widgets. Swing has been more visible, for a longer period of time, so third parties have developed powerful widgets for it. You're not seeing do-all Grid controls for SWT yet.

The two sort of dovetail together; if #2 happens for SWT, it addresses #1. It will be interesting to see how it all plays out.

I've enjoyed this week, and will continue to hang out here. Thanks for all the great questions.

Congratulations to the winners. I hope you enjoy the book, and I look forward to hearing your feedback.

I haven't seen a book dedicated to this topic, although many of the patterns books talk about it. One thing I've found is that if I at least design, and (even better) implement a command line interface for my GUI programs, the separation stays much cleaner. Besides, then the Unix folks love you

I realize that this won't work in every situation, but is more applicable than it might appear at first blush. For example, you might think this suggestion utterly inapplicable for an image editing program, but think about many of the functions an image editing program must perform. Convert among image formats? You can write a CLI for that. Apply some sort of effect to an image? You can write a CLI for that.

The trick, or course, is to make sure you're not writing two separate programs, and cutting and pasting code between them. Make sure you're using the same engine in both, and the interfaces (GUI and CLI) are just asking for and receiving input.

HTH.

Nope--you've got to download Eclipse to get JFace. Note that you must have SWT as well for JFace to work.

Yes, it is open source. It is licensed under the CPL, NOT the GPL. IANAL, but I understand the CPL to mean that you can do pretty much whatever you want with the source: use it, change it, distribute your changes, keep your changes for yourself, use it in commercial products, et al.

Chapter 12 discusses embedding the SWT Browser widget in your SWT app. Under the covers, SWT uses IE on Windows, Mozilla on Linux, and Safari on Mac. It uses something else on QNX--I forget what. Those are the only platforms that support the Browser widget, and you can't change which browser is used.

No, SWT and JFace are not for web development. SWT is a GUI library for building desktop applications. JFace is an abstraction layer on top of SWT.

You can, however, build fat clients that connect to the Internet. In fact, you can embed a browser in an SWT/JFace application. Chapter 12 discusses this.

The key difference is that SWT uses native widgets, and Swing widgets paint themselves. Native widgets will always conform to the desktop and behave like other native widgets, whereas self-drawn widgets will perpetually play catch-up.

Just because something is from Sun doesn't guarantee continual innovation; just because something is NOT from Sun doesn't mean no innovation.

SWTworkbench and SWT Designer are a couple. Be sure to check Eclipse Plugin Central for a wealth of Eclipse plugins.

Yes, it runs on a Mac. It supports:

Windows 98/ME/2000/XP

Windows CE

Linux (x86/Motif)

Linux (x86/GTK 2)

Linux (AMD 64/GTK 2)

Solaris 8 (SPARC/Motif)

QNX (x86/Photon)

AIX (PPC/Motif)

HP-UX (HP9000/Motif)

Mac OSX (Mac/Carbon)

(Taken from the Eclipse download page)

Ant has become the standard way to compile Java apps, supplanting make. It's actually simple to use, and very powerful. I recommend that you learn it--you won't regret it

No, I think both technologies will continue to thrive. I think the whole "Eclipse" thing is an affront to Sun (remember, an eclipse blocks out the sun). Also, they have invested quite a bit in Swing, so I can't ever see them pulling the plug on Swing and switching to SWT. Nor can I see such a terrific technology as SWT wilting or disappearing. I think we'll have the two Java GUI camps for the forseeable future. Just my $.02

The book does not cover this, but it's quite simple to do. Here's a snippet that demonstrates how to do it.

I haven't played with this much yet, and haven't seen any downsides (yet).

You can put an event handler on the close event for the window, but you don't have to. The shell knows that if the user tries to close it, it should close.