What's the deal with Swing?
Blake B.
shadoi at nanovoid.com
Wed Mar 29 08:42:40 MST 2006
It cracks me up that the posts in a thread concerning java are some
of the most verbose that I've read on this list in years. I guess if
you're used to coding like that, writing like that comes naturally.
Not that this is a bad thing, just humorous. (to me)
-Blake
On Mar 28, 2006, at 11:26 PM, Bryan Sant wrote:
> On 3/28/06, Dave Smith <dave at thesmithfam.org> wrote:
>> ross at indessed.com wrote:
>> I learned Visual Basic years ago, then AWT, then Swing, then Borland
>> Delphi, then SWT. Then, I picked up Qt. I've been coding in Qt (in
>> C++)
>> at work for about a year now, and I love it. Qt is the greenest GUI
>> pasture I've ever played in. Swing is the worst. Let me elaborate:
>
> Qt is awesome. The best UI toolkit in the world for sure. Too bad
> it's GPL or $2,500 per developer seat. :-(
>
>> Qt got it just right by providing an excellent graphical GUI
>> builder that
>> actually works!
>
> Having had used Qt Designer, I know what you mean. It is awesome.
> But the new Netbeans GUI builder is EVEN BETTER in my opinion. Forget
> about any Swing GUI builder you've used in the past -- I can't say
> enough good things about this new builder. So, yes Swing's API is
> verbose, but with the Netbeans GUI builder you write very little UI
> code. Just drag-n-drop like you did in VB/Delphi/Power Builder/Qt
> Designer, double click on a widget and write the snippet of code.
>
>> * Hard-to-use layout managers.
>>
>> One word: GridBagLayout (wait, was that 3 words?). I dislike Swing
>
> Ick. No kidding. GridBagLayout is a nightmare. The only reason I
> ever learned that was to pass the Sun Certified Java Programmer exam.
> I've never used it in a real app. Thankfully, the JCP has gotten the
> message, and now we have GroupLayout and the Netbeans GUI builder to
> replace it.
>
> But honestly, other than GridBagLayout, I think the Java layout
> managers are helpful and easy to use.
>
>> layout feedback wastes too much developer time. SWT got it slightly
>> better with FormLayout, which I found very useful. Then I discovered
>> Qt's layouts: horizontal, vertical, and grid. That's it. Super
>> simple.
>> Qt got it right, because widgets know how they are supposed to
>> stretch.
>
> Mustang's GroupLayout (used by the Netbeans builder) is even better.
> Also Java's BoxLayout works like Qt's horiz and vert layouts.
>
>> * Cumbersome Deployment
>>
>> Since we're talking about desktop applications, we have to mention
>> deployment. Java desktop applications are hard to deploy. I think
>> Java
>> WebStart is pretty nifty, but it requires a JVM to work! My
>> experience
>> porting from Java 1.3 to 1.4 was painful enough to teach me that Java
>> apps would have to ship their own JVM (meaning they would never be
>> able
>> to adapt to the already installed JVM at runtime). That's sad,
>> because
>
> No. As long as someone has a 1.5 or better JVM, the JNLP descriptor
> will tell them that they need a newer JRE to run your WebStart app (if
> you require a newer JRE) and the older JVM they have will know to
> download the newer JVM to run your app (with the user's permission).
>
>> the JVM is huge, even by today's standards.
>
> 16MB. I'm not saying that it's small, but the .NET 1.1 runtime is
> 22MB -- .NET 2.0 will be even bigger. It would take your averge user
> less time to download the JRE than it would for them to do their
> monthly Windows update... Or daily virus scan... You choose.
> Downloading Firefox and Thunderbird takes 10MB. So I disagree that it
> is big by "today's standards".
>
>> I used InstallAnywhere to deploy my Swing app at work, and that
>> thing took 30 minutes just to
>> build the installer. Now I use Nullsoft's NSIS, which takes about 3
>> seconds to build my Qt GUI's installer. All I do is install the
>> 2Mb Qt
>> DLL on Windows and I'm done. If I don't have that liberty, then I
>
> You can stil use NSIS with Java apps. I would. I hope you're
> distributing the Qt DLL legally. Either you've paid Trolltech $$ or
> your program is GPL right?
>
>> statically link the whole executable (which works fine on Windows and
>> Linux), and I have zero dependencies! Zero!
>
> That is sweet.
>
>> * Swing is ugly by default
>
> Java's new default ugly theme is less ugly that the old default ugly
> theme :-). With Java 5 and better the default theme is "Ocean". See
> here:
>
> http://www-128.ibm.com/developerworks/java/library/j-tiger10194/
>
> The top screenshot is the old default and the lower screenshot is the
> new default. This is just my opinion, but I think that most users
> would find that lower screenshot to be attractive and usable.
>
>> Last I used Swing, it was still "ugly by default." What I mean
>> here is
>> that Swing requires some heavy tweaking to make it look decent.
>
> This is not true any more. You do, as a developer, have to set the
> look and feel to be "System" as a command-line arg or in your Swing
> code at startup. But once you use the System look and feel, the app
> looks like all other Windows apps. On Linux you're still screwed
> until 1.6 ships and GTK looks good. But hey, choose another look and
> feel for Linux then:
>
> Choose here: http://www.javootoo.com/
>
> Who wouldn't want to use napkin look and feel :-) ?
>
>> Qt, on the other hand, is pretty by default. I don't have to
>> choose styles, or
>> subclass buttons to make my Qt GUIs look nice. SWT is pretty darn
>> good
>> in this respect too, but Qt is by far better.
>
> Qt does look good by default. But just for the record, you know that
> Qt is doing exactly what Swing does. It emulates the native look and
> feel (draws its own widgets). SWT is literally using native widgets,
> so SWT is "right" and both Qt and Swing have the possibility of being
> "wrong".
>
>> It is hard to use JCanvas. I've found QCanvas to be a delight to work
>> with, even with very complex display/interaction. QCanvas supports
>> animation, velocities, and double-buffering out of the box. Every
>> object
>> you create on a QCanvas knows how to draw itself, and you can
>> reposition
>> them with a single line of code, without having to worry about all
>> the
>> other items on the canvas. JCanvas doesn't provide such a powerful
>> API.
>
> I don't follow. At least in Java 1.5 and better JCanvas is
> double-buffered and it has always known how to draw itself. This is a
> common UI composite design pattern. I may be wrong (because I haven't
> worked with QCanvas), but I bet their API and capability is nearly
> identical. If you want to see some cool things done with JCanvas
> launch this with 1.5 or 1.6:
> http://www.jgoodies.com/freeware/jdiskreport/index.html
>
>> * Swing is slow by default
>
> You mean the *preception* is that swing is slow because people run
> blocking code on the the even queue thread.
>
>> It's bad to do heavy lifting on the event thread. Every GUI developer
>> knows this. Swing makes it hard to avoid though. So they invented the
>> invokeLater() hack, which ends up filling your code with anonymous
>> instances of Runnables (Runnable is pretty cool, though), which still
>> get run in the event thread, just a tiny bit later, resulting in a
>> slow
>> GUI. On the other hand, all of Qt's API is non-blocking. That
>> means you
>> can call QSocket.connect() and it will immediately return. The
>> QSocket
>> will notify you when it's done. The same is true of all of Qt's
>> classes.
>> In Swing, you would have to code all that infrastructure yourself.
>
> Java 1.6 has SwingWorker that solves this problem, but an even better
> solution is spin (http://spin.sourceforge.net/).
>
> Qt did do it right out of the box though. I'm not saying that Swing
> is on par with Qt, but the two are pretty close in terms of concept
> and ease of developerment (with Netbeans GUI builder). My turn off
> with Qt (it does have Java bindings) is that I have to pay $$ if I
> want to ship something that isn't GPL. Java is free (as in movie
> tickets) regardless.
>
> -Bryan
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
More information about the PLUG
mailing list