Defending Qt

Qt Logo

The Logo For Qt

Yesterday, byuu posted a blog entry expressing his disdain for Qt. I was surprised at this, since Qt totally rocks my world and has for a very long time. I fell in love the moment I first used it and have had very little trouble using it. I would like to defend Qt because for everything he complained about, there are a lot of good things that happen. Everyone’s experiences are different, but by doing things the “Qt Way” it usually works just fine. It is something about Qt that isn’t often mentioned: “Do it the way Qt is designed, or don’t use Qt.” It is the easiest way to get off track in a Qt application, trying shoehorn different technologies in without doing it the “Qt Way” will just bring heartache.
Qt also has, IMHO, the best documentation of any of the toolkits.
YMMV.

Feature bloat

Windows is the problem as pointed out in this quote: “…when your hello, world app needs 15MB of DLLs that no computer out there has already…”
The key acronym is DLL. Unix operating systems use shared libraries, not DLLs. If you are using Qt for Linux development, nearly every machine has Qt installed. Additionally, in a broadband-based world, 15Mb of shared library is seconds of download.

Reinventing the Standard Library

Qt has some historical baggage. When Qt was first started in 1991, the STL for C++ was unavailable without expensive licensing. It wasn’t until 1994 that HP made an implementation widely and freely available for use. It would then be many years before the STL became standardized enough on competing C++ implementations to be considered. The Trolltech developers of the time were somewhat stuck with having to make their own so that the multi-platform promise could be fulfilled.
GTK does this, too, with GLIB.

Qt internally uses UTF-16

There are specific benefits from Qt’s use of its own library. QString, for instance, can transliterate between any character set it supports; std::string cannot, as far as I know.
Byuu was upset about the choice of UTF-16. I suspect this is also a historic issue. Java made the same choice around the same time to use UTF-16 as the string encoding. These decisions were made at a time when the only two encoding that existed was UTF-16 and the decision had been made that ASCII would be a subset. John C. Dvorak’s famous “Kiss your ASCII goodbye” article described Unicode as having 64k characters vs. AsCII’s 256. This lines up with what I have read in other articles, but please correct me if I am wrong.
It only becomes a difficulty when converting between different encodings. In my Qt development, I have not found it to be a problem. Most of my strings are wrapped with tr(), which handles most of the common cases for you.

Signals and slots

Qt does not use templates to implement signals/slots because support at the time was poor. Callbacks aren’t used because of several reasons. According to Trolltech (now Nokia):

Callbacks have two fundamental flaws: Firstly, they are not type-safe. We can never be certain that the processing function will call the callback with the correct arguments. Secondly, the callback is strongly coupled to the processing function since the processing function must know which callback to call.

Qt uses as preprocessor called moc that generates support code to enable the signals/slots mechanism. This has been criticized, even by me, but I learned to love it. The code that gets generated enables run-time reflection of QObjects, some basic garbage collection, and support for the signals/slots mechanism. The metadata allows tools like Designer to introspect objects and provide their use in building a gui.

All GUI toolkits have problems

I suppose my final thoughts are that every GUI toolkit has problems. I understand that Byuu was complaining about his own frustrations and really saying that Qt is bad but not needfully worse. It is a trade-off, like anything. I have encountered a few bugs in Qt, but they were all in multimedia/audio support and have been largely addressed.
All of that said, I am hoping to see more use of STL and Boost libraries when Qt 5 eventually comes around, hopefully after C++0x has become more stable. The library represents state-of-the art GUI toolkits in the late 1990s, and a lot of it is starting to show its age. Qt Quick and the technologies introduced in version 4.7 are a good start but there is still a long way to go.
C++ GUI Programming with Qt 4 (2nd Edition) (Prentice Hall Open Source Software Development Series)

Related Posts:

  • No Related Posts
This entry was posted in Programming and tagged , , , , , , . Bookmark the permalink.

3 Responses to Defending Qt

  1. byuu says:

    Hi, thanks for the response and for reading my article.

    > The key acronym is DLL. Unix operating systems use shared libraries, not DLLs.

    That is a blessing and a curse. First, Linux users are 2% of the market (I am one of them.) Second, when a bug appears in the Linux Qt run-time, it means you’re stuck with it until your distro upgrades in 6-24 months.

    > Additionally, in a broadband-based world, 15Mb of shared library is seconds of download.

    There is a site that has hundreds of game hacks, and these hacks are distributed as patch files. Due to bandwidth costs and storage size, they include a lightweight, 20KB IPS patcher along with the ~100KB patches. To include my UPS patcher would be to include a 5MB program with each patch.

    Also, I live in a country (USA) where broadband operators have a government-sanctioned monopoly. There is no real competition here.

    > When Qt was first started in 1991, the STL for C++ was unavailable without expensive licensing.

    Yes, but Qt4 was not backwards-compatible with Qt3. Perhaps the worst part is that I personally find Qt’s container classes better than what finally made it into C++98. It’s just one more thing you have to work with.

    > Byuu was upset about the choice of UTF-16. I suspect this is also a historic issue.

    It’s the same as above. UCS2/UTF-16 came out first, and it’s what Microsoft went with. I begrudge that Qt chose to sacrifice backwards-compatibility with ANSI libraries to better fit the Windows model. There are about 700 calls to QString::toUtf8() in my application, which gets tiresome. I wrote a wrapper around my string class (a conversion constructor) to do the fromUtf8() for me.

    I cannot understand why Qt would chose UTF-16 for Qt4. It combines the incompatibility toward libc with the O(n) character access and length of UTF-8. It’s the worst of both worlds. The only positive is slightly less memory usage, which … who really cares with today’s 8GB machines? Your text label takes 40 bytes instead of 30, wow.

    > Callbacks have two fundamental flaws: Firstly, they are not type-safe.

    This is no longer a problem in C++0x, thanks to std::forward. However, that is a good point as even Qt4 cannot reasonably use C++0x yet. My article takes for granted using an incomplete standard because I find it is worth the benefits.

    > Secondly, the callback is strongly coupled to the processing function since the processing function must know which callback to call.

    Qt does this behind-the-scenes anyway. That’s how the signal knows which slots are bound to it. I do not see why this really matters.

    > The code that gets generated enables run-time reflection of QObjects, some basic garbage collection, and support for the signals/slots mechanism.

    It does a lot, certainly. Almost all of it can be done using C++ templates, and the rest is so extremely niche as to not be worth the requirement of a pre-processor, at least in my opinion. But it’s easier to dismiss features you don’t personally need.

    > I suppose my final thoughts are that every GUI toolkit has problems.

    Yes, they most certainly do. Every toolkit and even every native API I have used has failed to consistently handle callbacks. Take Qt, if you call comboBox->setCurrentIndex, it will call your currentIndexChanged signal. Yet if you call checkBox->setChecked(), it will not call your stateChanged signal. Every API messes up this basic detail.

    But by far, Qt is the buggiest of any toolkit or API I have ever used. I am constantly finding new bugs with every UI feature I add. It’s a LOT more work to write the GUI for every platform I target, but I feel the added work will pay off for my users in terms of stability. And that is why I cannot recommend Qt, as much as I love the overall coding cleanliness, powerful features and unified development model.

    I think there is hope, what we really need is a Qt-lite, with a serious focus on reliability and size over features and flexibility.

    • admin says:

      Thanks for replying to my reply :).

      I have to admit, my bias is heavy on Linux and the tasks I currently use Qt for; database-backed audio processing applications. Only speaking from my own experience, I did not have a good experience with toolkits other than Qt. It was the least painful for me, but I also don’t really have to contend too much with users because my requirements have been limited to constrained corporate enviroments and I don’t really write anything for Windows if I can help it. (I should add that I started with Qt3 in 2003, and have been writing Qt code since, so I’m not new to it.)

      I recently had UltimateApp suggested to me by a Boost booster and will likely give it a look when I get a chance.

      I completely agree with the need for a Qt-lite, but I wonder if that is going to end up, to my horror, being HTML5.

    • mat69 says:

      “Take Qt, if you call comboBox->setCurrentIndex, it will call your currentIndexChanged signal. Yet if you call checkBox->setChecked(), it will not call your stateChanged signal. Every API messes up this basic detail.”

      You did not read the docs there.
      toggle(bool) is emitted if you call QCheckBox::setChecked(bool).

      Further there is a reason that Qt does not use a lot of std stuff. One is that they prefer a different type of API and the other is that not all compilers they support, support those features. There are still compilers around not complying fully to C++ 98.

      e.g. http://labs.qt.nokia.com/2009/08/25/count-with-me-how-many-smart-pointer-classes-does-qt-have/