It turns out that's not the case. There is an ACCESSIBILITY api which Qt implements that allows the OS (Windows) to "read" text and control the GUI in the non-native widgets.

This, and the fact that it's much more simpler to do things by subclassing the C++ way.

I also have wxWidgets experience, and here is my summary: Lots of Leaky Abstraction. For example - try to get the current line of a text-edit control - internally what wxWidgets does (or was doing time ago) was to send message to the control, but if the control did not support the message, it had to reparse the whole text, and based on your byte-position count how many CR-LF were there and give that information to you.

e.g. it was hard to predict which operation is going to take this and that much of time.

Qt is not without pitfalls, and missing features - Visual Studio Docking like windows for example that supports multiple monitors, but other than that it was much easier for our team to use it, rather than MFC or the Win32 API, and even wxWidgets.

It is not so black and white. For example when there is a button when possible Qt will ask the native system to draw a button with properties x,y,z at location x,y So it might be a QPushButton, but it is the OS X or Win32 library that is doing the painting that the user sees.

Of course on Windows the idea of "native controls" is confusing as many Microsoft apps have their own "native controls", which one is the native control? I am guessing WXWidgets simply picks the lowest common denominator one and moves on.

They are native controls on X11. Or, more accurately, X11 has no native controls. The closest is probably XAW, which is so awful it was dropped decades ago. There are QT themes that will use GTK for rendering, though.

(For reference, a screenshot of XAW: http://www.iue.tuwien.ac.at/phd/halama/_13595_figure4289.gif The box with 'Athena Simple Widgets' is what is provided by X11.)