One thing I would note is that Swing isn't as bad as you make out - there are three main problems - one is that there's a lot of very badly written code out there, thanks to "Java applets for dummies" books and the like, another is that people persist in using (definitely flawed) AWT components, and the third is that people are still using the 1.1 swingall.jar swing instead of 1.3 swing, thanks to MS and Netscape faffing.

The Beans/Swing event handling model is very similar to signals and slots to program (although not in its actual implementation), and I assure you that _my_ swing code is only a little more verbose than Qt code for equivalent functionality, and that reflection-based at-runtime eventlistener connections are possible, and easy to do. There is stronger type-checking on java's events than Qt signals, though, so you have to explicitly deal with different exceptions when you do dodgy things.

That's not to say I don't prefer Qt programming though! - just that swing is actually not that bad a toolkit (better than programming Gtk in C, anyway, although Gtk--, again, isn't all that bad - I dislike Qt's moc, especially since new C++ compilers have sufficient template support to render it obsolete...), provided you learn it from a decent, i.e. O'Reilly or Sun published, book.