2. The widgets are very limited. For example, the table view requires hacks to support clickable links. Not custom delegates or label but hacks. HTML/JS widgets are way more flexible than Qt widgets. That says a lot.
In general, if you're trying to make a really usable app, Qt widgets just get in the way. If you're trying to make a regular ol' form-based UI, with perhaps a OpenGL viewport for the real fancy stuff, it's actually perfect.
What I end up doing is using Qt for the event loop and window management, but do everything else myself except where it's obvious that Qt can handle it.
There are very few apps where you need to do this kind of thing though, so for the majority of people, it's actually OK.
Also, QML is a pretty awesome technology. I'm looking at how to use it to speed up development.
Edit: I just want to say it's quite probable I'm stupid.
Also, QML is a pretty awesome technology. I'm looking at how to use it to speed up development.
Unless I'm doing basic forms, like you said, I've actually been using QML for desktop apps (that is, I place a QDeclrativeView in my form and implement as much of the UI as possible inside that, in QML). From what I've seen on the Qt Labs blogs, this is what they are planning for desktop apps in Qt 5: QML for the UI, C++ extensions and QWidgets available should you need them. (If you don't need or want to embed the UI inside a QWidget, then you don't need QDeclarativeView and use the QtQuick launcher instead - you can still implement QML extensions in C++ and embed QWidgets and such)
So, yeah, QML is the way of the Qt future.
As for the limitations you mention:
1. Implementing models are way too complicated.
So far, I haven't needed to do very much with models, so this hasn't got to me yet, but they do look pretty complicated... so no arguments here.
2. The widgets are very limited. For example, the table view requires hacks to support clickable links. Not custom delegates or label but hacks. HTML/JS widgets are way more flexible than Qt widgets. That says a lot.
I haven't noticed this really. Ok, yes, once you need lots of custom logic, you do end up having to derive your own widgets so you can intercept events and emit signals and so on, which can get complicated if, as is the case with table views, the widget is some kind of container which interacts with some kind of container items which you must also derive from. This definitely needs to be streamlined somehow (I'm hoping that a lot of this can be eliminated through QML), but it hasn't struck me as "limited".
As for the support stuff... I used to like QtConcurrent - but then I started using TBB and have no need for it now. I like the Qt containers because I can use foreach (of course, this is solved by C++0x), but I tend to use the C++ Standard containers or the TBB containers more often, unless the code only interacts with Qt and very little custom or (non-Qt) library code.
It's limited because you can't end up with a completely proper solution. Then you have to make a tradeoff between functionality, complexity and even performance for something as simple as the example I gave above.
I think QML is an even better case for form-based UIs.
Completely declarative, everything is automatically bound, what's not to like?
