Qt에 대한 단상 몇가지

1. 바이너리 크기가 생각보다 큽니다: Qt Quick Controls 기반의 GUI 프로그램을 만들려면 이정도는 갖고 있어야 합니다:

• Qt DLL(22MB: Core, GUI, Network, QML, Quick, Widgets)
• ICU(26MB)
• Qt Quick Controls QMLs and support DLLs(20MB)
• 그리고 기타 필요한 것들

뭐 이쯤 되면 DLL hell은 당연히 열리고도 남게 마련입니다. 특히 Qt Quick Control을 쓰게 된다면요. ;)
몇몇 기능을 제거하면 프로그램 크기를 줄일 수는 있겠지만, 가장 간단한 “hello world”급 프로그램을 띄우는데만 해도 15~20MB정도가 필요합니다. 몇몇 경우, 특히 간단한 업무용 프로그램용으로는 배보다 배꼽이 더 큰 경우가 발생하기도 하죠(파일 의존성 관리라던가, 유지보수라던가……).

2. 상용 라이선스 구매자들에 대한 혜택 증가: 이를테면 Qt Quick Charts나 Qt QML compiler같은 것들이 예시가 될 수 있겠습니다. 물론 상용 라이선스 구매자들에게 더 좋은 서비스를 제공하는 것은 당연한 일입니다만, 물론 Digia가 Qt의 개발에 꽤 괜찮은 성과를 보이고 있긴 하지만, 때로는 너무 돈 낸 사람들만 신경쓰고, 오픈소스 커뮤니티는 홀대하는 건 아닌가 하는 생각도 듭니다.

3. Digia는 Qt 프로젝트에서는 꽤 좋은 성과를 보여주고 있지만, 재무상태가 생각보다 썩 좋은 것 같진 않습니다. 이 포스팅(http://worldcadaccess.typepad.com/blog/2011/03/nokia-sells-qt-cad-vendors-hearts-go-pitter-patter.html)과 회사의 재무현황 지표를 참고해보세요(http://www.digia.com/en/Company/Investors/Financials/Key-Figures-Monitor/).

4. Model-Delegate-View Framework는 생각보다 손이 많이 갑니다: Qt의 model-delegate-view framework는 QAbstractItemModel의 사용을 강제하는 경향이 있고, 이 모델은 구조상 복잡성 때문에 간단한 데이터 표시용으로 쓰기에는 너무 복잡한 경향이 있습니다. 데이터 추출이나 가공이 복잡하다면 이 프레임워크는 꽤 유용한 도구와 인터페이스지만, 대부분의 경우 저는 LCL(Lazarus Component Library)에 있는 TStringGrid가 그리워지더군요.

5. Qt Quick Controls는 아무리 봐도 뜨거운 감자일 뿐: Qt Quick은 위대한 기술입니다. Qt Quick Controls는 widget처럼 생긴 화면을 Qt Quick 위에서 사용할 수 있게 해주는 또다른 기술개발의 결정체입니다. 문제라면…… 라이브러리가 너무 크고, Qt Quick의 JIT 컴파일러 기동때문에 시작이 늦고, Digia가 꽤 여러가지로 신경을 쓰긴 했지만 C++쪽과의 통신도 그렇게 썩 매끄럽지는 않은 것 같습니다. 그렇다고 이걸 안 쓰자니 Qt Quick의 무한한 확장성을 버리는 꼴이 되고…… 최근 추가된 QQuickWidget이 이런 부분을 어느정도 상쇄해 주긴 하지만, 그렇다고 본질적인 문제가 완전히 해결되지는 않아 보입니다.

6. 기능-성능 tradeoff: Qt는 GUI 라이브러리가 아니라 응용프로그램 개발용 종합 프레임워크로 보는게 옳을 것입니다. Qt에는 프로그래머를 편하게 해주는 다양한 기능이 있지만, 이들 기능을 위해 성능을 희생하게 되는 경우를 종종 보게 됩니다. 저도 제가 직접 만든 linked list가 QLinkedList에 비해 5배 이상 빠르게 움직이는걸 경험했고, Google에서 잠깐만 검색해보시면 STL이 Qt보다 더 빠르다는 이야기를 쉽게 찾으실 수 있을겁니다.

Qt가 대단한 기술임을 부정하고 싶지는 않습니다. 저는 Qt를 매우 좋아하고, 지금도 수많은 프로젝트들이 Qt로 돌아서고 있습니다(특히나 wxWidgets에서 오시는 분들이 많더군요). 하지만 Qt를 선택하기 전에 몇몇 생각해봐야 할 부분이 있는 것 또한 현실입니다. 한 1년여 Qt를 특히나 최신버전 중심으로 사용해보니 몇몇 어두운 부분이 보이더군요.

저요? 전 가끔 제 생각에 ‘이건 아니다’ 싶으면 주류를 화끈하게 벗어나는 경향이 있고…… 그래서 전 이번에도 Qt에서 wxWidgets로 이전해 보려고 합니다. 제가 만든 단순한 프로그램들의 배포를 위해서 수십개 파일의 의존성을 관리하기에 저는 너무 게을러요. :(

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.