This is a completely fair point, however I think it's worth pointing out that especially considering the broad range of stuff Qt covers by itself, it's actually quite willing to intermingle with standard C++, and has continued to inch closer to standard C++. For example, Qt's containers work with std's algorithms (including the new C++11 iteration protocol) and Qt 5 introduced a new form of the signal/slot connect that's type-safe, based on templates and can connect to any callable (so including lambda, wheee ...), instead of being a macro that operates on normalized signature strings and annotated methods (while also still allowing you to ditch Qt signal/slots and use e.g. boost's if you prefer).
And there's of course also a lot of historical reasons for the overall approach - when Qt started out, standard C++ was significantly weaker both in what the standard contained and how the standard was available. That's not to say I think Qt's mode of operating is obsolete, though; a lot of the value of Qt comes from good API hygiene (pleasant API design, consistent API pattern reuse), and I find that having my $usecase be met by a nice Qt-style API is generally a pleasant discovery.
Interesting, I'm wondering how Qt types make porting more difficult? My experience has been that if I only used standard-C and Qt types, I had no issues in porting. A recent project I worked on only had a handful of platform checks (and all but one of them were in the project file), and compiled fine on all platforms. In fact, I developed it entirely on OSX first, and then simply adjusted the build to support the different OSes later, and didn't have a single problem.
Mind you, I -only- used Qt standard libraries (except QExtSerialPort which was the best option for serial access at the time I started the project).
I definitely agree with preferring Q-types to STL. Combined with Creator as an IDE, it's brain-dead simple and I spend my time on higher-level concerns. (FWIW, I wish Creator had more languages supported, I've never had such a wonderful experience in any other IDE. I want to shoot XCode every time I open it, mostly because Creator has spoiled me on how good auto-complete can be.)
If you already have a codebase that's littered with STL, you need to make a few changes here and there. I was thinking about "porting your codebase to Qt", which isn't quite a correct usage. Sorry, it was kind of late in the evening :(.
And there's of course also a lot of historical reasons for the overall approach - when Qt started out, standard C++ was significantly weaker both in what the standard contained and how the standard was available. That's not to say I think Qt's mode of operating is obsolete, though; a lot of the value of Qt comes from good API hygiene (pleasant API design, consistent API pattern reuse), and I find that having my $usecase be met by a nice Qt-style API is generally a pleasant discovery.