| I tried for a few years to use Qt. This is kind of old now, from 4.5-4.9 or so, but I think a lot of the points are still valid: https://web.archive.org/web/20120429043003/http://byuu.org/a... These days I do the same: I have an abstraction layer that can back-end to Windows, GTK, Qt, and for a time, Cocoa. A huge advantage is not needing those run-times on Windows, which comprises 90-95% of the desktop market still. On average, Qt is around 40MB of DLLs. Even if you: compile it yourself with -Os, use a 40-line configure to disable everything possible, and upx --best the resultant DLLs (or binary if you statically link), you're still looking at ~5-10MB. You can say that's not much today, but say you do one release a month at 100K downloads (which I did), that's 500GB-1TB of bandwidth gone, just for a run-time. Now imagine 1M, 10M downloads. This is a big deal when your tool is only ~50-200KB by itself, and you are giving away free software without ads. Another problem is that Qt may use the native theming engine, but it most certainly doesn't use truly native widgets. Because it needs to do a lot of stuff the native platforms can't: like its CSS-style theming. When you move beyond the absolute basics, the seams start showing up. It's especially bad on OS X. Next, there's the bugs. I was constantly encountering major bugs in Qt, and for Linux at least, you can't just patch Qt. You have to wait for the next distro release cycle before they are fixed, so you end up with dozens of platform-specific workarounds, which really undermines the point in the first place. You can ship your own 150MB of Qt source, but no Linux distro will use it for their packaging. If you have your own abstraction, you can go in and fix bugs immediately. Lastly, it's the portability. Toolkits like Qt try and do a trillion things. That's lovely, sure. But if you know you'll never need those things, it's nice to limit yourself to a smaller subset. That keeps the API simpler and cleaner, reduces the amount of possible bugs, and makes it substantially easier to port your applications to new platforms. Imagine a new platform comes out, and either Qt is discontinued or uninterested in it. Porting Qt yourself would probably need 3-5 man years of work. But porting your own basic abstraction layer could be done in 3-5 weeks instead (the time is relative to the complexity of it.) All this said ... I'd much rather have had someone else write the toolkit abstraction for me, but I couldn't find any that I liked. They were all too big, too small, too unportable, or too difficult to use. |