On 3/28/06, Dave Smith <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] 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.
*/
