Some thoughts about Qt nowadays

1. The size of the binary is too large: to open a GUI application with Qt Quick Controls, you should have

• Qt DLLs(22MB: Core, GUI, Network, QML, Quick, Widgets)
• ICU(26MB)
• Qt Quick Controls QMLs and support DLLs(20MB)
• And anything you want

And of course, the DLL dependency hell is open to you, especially if you use Qt Quick Controls. ;)
You can minimize the application size by deactivating some features but still it’s about 15~20MB for simple “hello world” application. Sometimes it’s too heavy to bring all the files for only simple tasks.

2. More benefits to commercial licensees: Qt Quick Charts, Qt QML compiler, and so on. It’s of course fair to give more to commercial licensees but I’m afraid their(Digia’s) efforts ar skewed too much to its customers, though I know that they did quite good job on developments of Qt.

3. The financial status of Digia seems not as good as its leadership in Qt project. Check this post(http://worldcadaccess.typepad.com/blog/2011/03/nokia-sells-qt-cad-vendors-hearts-go-pitter-patter.html) and the financial status of the company itself (http://www.digia.com/en/Company/Investors/Financials/Key-Figures-Monitor/).

4. Model-Deligate-View Framework, overcomplicated: the model-delegate-view framework of Qt seems to make the data represntation overcompilcated as it forces to use QAbstractItemModel deligates to display items. If the data gathering and manipulation is complicated the framework provides useful tools and interfaces to interact, yet most of the time I long for my beloved TStringGrid in LCL(Lazarus Component Library).

5. Qt Quick Controls, a hot potato: Qt Quick is a great technology and Qt Quick Controls is yet another great creation as programmers can make use of Qt Quick technology inside what seems to be the legacy widget-looking interfaces. Yet the size of support library is too big, startup is slow as Qt Quick JIT compiler needs some time to initialize, and it’s still a bit painful when communicating from/to C++ side though Digia did good job in interface handling. Of course you can use Qt Widgets but in this case you lose the unlimited extensibility and power Qt Quick has, though recently added QQuickWidget class complements things a bit.

6. Feature-performance tradeoff: Qt is not just yet another GUI library. It’s rather an application framework from the bottom. It has so many features which makes the programmer convenient, but to support many features it had to sacrifice some performance. Among my personal experiences, I found out my own linked list worked about five times faster than QLinkedList. Or, just google it and you can read so many articles that performance of STL is similar or better against Qt ones.

I don’t want to deny Qt is great technology. I really enjoy using Qt, and even now more and more projects turn to Qt(especially from wxWidgets), meaning there are more programmers who feels like me. But there are things you should consider when choosing Qt. I just wanted to describe some “dark side” stuff against Qt after using the technology for about one year or so, chasing the upstream.

My answer after all those situations? Sometimes I was against the mainstream if I think so. I’m moving from Qt to wxWidgets. I’m too lazy to manage tens of files for only simple applications I make.