The Fugue

I've extolled the virtues of QtRuby before. As GUI toolkits go, Qt is the best (IMHO) and as languages go Ruby is tops (again, IMHO), so naturally QtRuby has potential. QtRuby's biggest stumbling block in the past has been installation. Easy on Linux, but deep voodoo on OS X and perhaps even worse in Windows. That has finally changed.

qt4-qtruby now uses a cmake-based build system. I installed Qt4 from source on my MacBook, then followed the instructions to install qt4-qtruby and gave it a spin. Everything worked perfectly out of the box.

I can't speak for Windows, but QtRuby on Linux and OS X is now practical. (It has been since June or perhaps earlier, but I just got around to trying it out.) Celebrate!

Back when Qt 4 was released, I watched "The Qt 4 Dance". It's silly, catchy, and, well, cute. Somehow the mp3 got wedged in my iTunes and I've heard it a few more times since then. Not the worst song in the world, but I wish I could get rid of it.

What I don't wish is to get rid of Qt 4. I didn't actually look at Qt 4 until a few weeks ago. I didn't believe that Qt 4 could solve all my problems, no matter how great it was for Jean-Claude. When I had to do any GUI programming, I was happy with Qt 3.

With the move to the MacBook, Qt and qtruby needed installing, and I decided I might as well install the Qt 4 versions. Qt 4 for OS X is much improved just in the distribution and packaging. qt4-qtruby is slightly easier to install than the Qt3 version, but it still needs some packaging work. Finally I had gotten qt4-qtruby installed and then I tried to fire up Neelix and discovered Qt4 doesn't just run Qt3 code automatically.

So I investigated a bit and decided to port to Qt 4. It was a bit of a long process, and perhaps a bit painful, but it was like the muscle soreness you get after a good workout. At the end I didn't feel like "what a complete waste of time", but excited for the new possibilities.

You see, the major differences between Qt 3 and Qt 4 are architectural. Some stupidity has been replaced with elegance. Believe me, refactoring your code to use the new Model/View framework for tables, tree views, etc. instead of the old item-based tree and table views is an exhilerating experience. The old way is klunky. The new way is elegant. If I had to pick one reason to prefer Qt 4, that would be it.

But there are other great changes too. Take a look at the What's New in Qt 4 page. I'll just rattle off a few of my favorites: a better main window class, Qt Designer improvements, integrated SVG support, PDF printing backend, unit testing framework, syntax highlighting class, splitting things up into modules (this should make gentoo users giddy), C++ namespaces, OS X improvements, a Calendar widget, a text completion framework, an undo framework, it's open source on all three platforms, and much more.

Another favorite change isn't on that page, but deserves mention. In the old days you'd design a window with Qt Designer and then you'd have to do klunky things like subclass widgets to get all the functionality. I never really liked that. Qt 4 takes a much more elegant approach, IMHO. You can still subclass if you're an OO freak, but that is deprecated. uic now hands you a POD class which will populate a given QWidget for you. So in my code I create an instance of this POD thing, create a main window widget, then pass my widget to the POD's setupUi() function. Et voilá, I have a populated main window. No subclassing. I can access all the widgets as members of the POD.

If you're in C++ and thinking of porting your code to Qt 4 it's not as much work as I led you to believe above. Qt 4 has a compatibility layer and an automagic tool to convert your Qt 3 code to Qt 4 code (and Qt Designer and/or uic will convert your .ui files). qtruby users will need to just port it, because qtruby doesn't support the compatibility layer for reasons I reluctantly agree with.

So in the end, Qt 4 *is* worth dancing about. Fancy that.