I remember it as being quite a nice library with a decent API for its time. There are probably some useful lessons to be learned from its longevity.
(1) It's stable. No "let's rewrite everything every two years!" It's a bit ugly but once you learn it you know it.
(2) It targets a reasonably stable set of platforms.
(3) It's not over-ambitious. It doesn't try to be its own rendering engine or implement pseudo-style-sheets (I'm looking at you Qt) or do other crazy things. It just wraps a minimum common denominator of desktop UI functionality sufficient to ship a good working application that's not too ugly and is usable.
As such it's great for long lived C++ code bases that need UI functionality across platforms.
You're better off just using qt: they put a lot more work into making it a useful environment, it runs a lot more places.
But you know why, right? It's because it's supposed to be both cross-platform and native, so a particular platform may not use a nested label widget in a tabbed window, so it can't give you such an object.
If you look at the Windows implementation for the wxNotebook (which I guess is the class you mean), you can see it doesn't use a nested widget for the tab label. The field may exist, but this implementation doesn't use it and instead it uses standard Windows API calls like TabCtrl_SetItem, which doesn't allow you to set a font. It only allows you to pass in a char* string.
https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/n...
https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
So on Windows what do you expect it to give you if you ask for the label widget if there isn't one? Pretend there is one and give you some kind of facade object? What should happen if you try to set the font? Since the API they're using just doesn't support it.
I think the Windows API may allow you to subclass a tab to draw it yourself and use fonts, but that's asking a lot. And there still isn't really any label widget for them to return even if they did that!
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.
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.
Note also that Wx runs on top of Qt. Why not drop Wx and just use Qt directly?
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.
The illusion is pretty much pixel-perfect.
I don't particularly care about the host platform; I write software that runs on all 3 major platforms, and having it behave mostly-consistently across the platforms is more important than being consistent with the host platform.
If you need to do weird things in a non-native way then wx probably isn't for you. If you want to write software that looks and feels like a native application (because it is) then wx is your best bet.
Qt is great but I've never used Qt application that felt like a native application. Also, Qt is rather expensive for commercial projects (about $4k per year per developer).