In the case of windows, you can either use the char * methods, or you have an owner-controlled widget which is a rendering area. That's what Qt does. Combined with Qt's windows style, you get somethign that looks native by default, but is customizable.
This seems to me to be a far more productive approach that trying to come up with an API that supports only the common subset of features shared between Apple's UI toolkit, Windows UI toolkit, and Linux. Note that qt also supports embedded devices with raw frame buffers; you can make a UI that looks nearly pixel identical to Windows on that platform.
> This seems to me to be a far more productive approach that trying to come up with an API that supports only the common subset of features shared between Apple's UI toolkit, Windows UI toolkit, and Linux.
But an API with the common subset of features is the whole philosophical point of wx! If you're going to criticise them for that you might as well criticise screwdrivers for turning screws. That's what they were built for.
Well, then I disagree with wx's approach. Not only is it more inflexible, the qt solution of creating a styled UI that can be adapted to look native, while being portable and not preventing people from customization, seems to be more flexible.
Note also that Wx runs on top of Qt. Why not drop Wx and just use Qt directly?
Wx doesn't run on top of Qt, it simply has an option to use Qt as its back end engine in place of e.g. the Windows native API. You can do a Windows build that doesn't have Qt anywhere in sight.
> Yes,you are correct: Qt uses themes and styles to configure its internally rendered widgets so they appear native.
Oh wow, I have developed QT applications and never even noticed that. Sure, on Linux I know that it draws the controls, are there are no standard controls. But I figured they just had a pretty good integration and didn't bother looking under the hood.
You will notice it most when Microsoft updates the look and feel of the standard widgets in a new version of Windows. The Wx app will pick up the new look automatically, the Qt app will need to be updated.
http://doc.qt.io/qt-4.8/style-reference.html
In the case of windows, you can either use the char * methods, or you have an owner-controlled widget which is a rendering area. That's what Qt does. Combined with Qt's windows style, you get somethign that looks native by default, but is customizable.
This seems to me to be a far more productive approach that trying to come up with an API that supports only the common subset of features shared between Apple's UI toolkit, Windows UI toolkit, and Linux. Note that qt also supports embedded devices with raw frame buffers; you can make a UI that looks nearly pixel identical to Windows on that platform.