Interesting, one wonders if there will be some de-duplication in the far future. There is a lot of overlap with TR1, for instance Qt's smart pointer and container classes.
On the other hand, I guess many Qt users will treat Qt as the C++ standard library ;).
I do a lot of C++ Qt programming and I often have a hard time deciding if I should use. The most common is should I use QString for in my code easy interaction with Qt, or std::string for easy interaction with other, non-Qt, libraries that I use?
I also sometimes wonder what I should use when I do multithreaded stuff (which I often do, because I like multicore stuff) - for example, if I want heavy-weight threads (as opposed to tasks, which I always use Intel Threading Building Blocks for), do I use C++0x? Do I use QThread? Do I use the TBB threads wrapper?
If I am not using third party libraries, I do prefer to use Qt over the standard library, simply because it keeps everything consistent (less conversion between std::x and Qx)
Outside of basic windowing functions, Qt is pretty awful. I don't even use their widgets unless I am creating a form UI or a normal widgety app. I basically use Qt as a gigantic wrapper around native GUI event loops.
I only use QThread if I need to do QImage stuff in a thread (I think this is strictly not necessary, but safer imo).
Conversion between QString and my::string are there but I have not found them to be very problematic. I guess it depends on how often you are doing these conversions.
In short: Qt sucks, but like democracy, it's the best of the worst.
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?
On the other hand, I guess many Qt users will treat Qt as the C++ standard library ;).