Qt also has, IMHO, the best documentation of any of the toolkits.
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)