I really wish they would put at least one developer on getting some of their basic features requests done.

For example, I wanted to use Chrome as my HTPC browser as it does a good job scaling it's plugins to the system 2x DPI (unlike Firefox where flash applets are tiny squares in big dark frames they are supposed to fill).

But Chrome does not save the full page zoom setting! Every time you open a tab or browser instance you have to Ctr + which becomes unusable. It has not browser-wide options related to full page zoom and their font options are confusing and seem to make no effect.

Worse is the how easy it is to fine lots and lots and lots and lots of people complaining about this on their own help forums without a single response from the developers.

I know they are avoiding feature creep and keeping things slim, but even by a 80/20 rule, this kind of thing should be picked up (and could even replace their useless font settings dialog).

Actually, it's probably not just him.

Qt4 has larger spacing margins and padding on widgets by default in there layout system than Qt3. Also, I believe KDE4 uses larger fonts and more anti-aliasing than KDE3 systems, so the same dialog with the same set of widgets and text most likely is larger in KDE4 on a pixel basis.

That said, you can probably control this to some extent with font settings etc, but the widget padding and margins are up to the application developer.

For the core purpose of Qt (GUIs), Qt's various memory models work very well. Every widget is a QObject and by default they fall into parent child releationships that include life-cycle management of your objects. Why would you want to mess up that clean model?

Another unnecessary generalization. I actually much prefer Qt's collections because A) they are implicitly shared (you can pass them around without getting deep copies) and B) they have one clean and very efficient implementation across platforms, so I don't have to worry about the memory and performance characteristics of a MSVC std::map vs a GCC std::map. Also they are much cleaner to work with and don't require hideous iterators every step of the way.

Again, Qt threads will perform as good as native threads on each platform, something you can not guarantee with pthreads (with weaker windows support). Also, QThread and friends (QMutex, QSemaphore, QWaitCondition, QThreadStorage) are very C++ oriented and stylistically much cleaner than pthreads and even go beyond it in scope.

This is probably the most valid argument, and there is some legacy reasons why Qt had to throw a meta object compiler on top of C++ to get this to work 18 years ago. But in the mean time, that moc layer has paid off in gold. Now you the ability to get free introspection on classes of your choosing which is vital in making C++ suck less in well designed programs (i.e. can do automatic class instance serialization etc).

In other words, Qt is a great one-stop-shop for cross platform development and I wouldn't change a single thing you listed. In fact, if you write your C++ code in stylelistic keeping with the Qt libraries, you avoid most of C++'s warts and can even enjoy the language.

I won a QT greenphone http://www.trolltech.com/products/qtopia/greenphon e/ at QT DevDays 2006.

It's completly open from the Linux kernel, to Qtopia as a operating system to the user apps. You could even hack the modem device driver if you wanted too.

Unfortunatly it's set up as a developer device and not available to the public, it's GSM (not good coverage where i'm at) and still a bit buggy.

On the upside it's fun to hack and you can be sure the FBI has no backdoors :)