> I submit that Wx implements its own non-native widgets.
It does for the widgets that have no native equivalent, such as draggable/dockable tabs/panels that you show. You can't say they differ from native ones because there is just no native version, on any platform.
OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native and not only they look natively, but also behave natively, which is pretty important and different from Qt.
Not the person you responded to, but can you explain why if they're using native widgets, every single example application here [1] looks horribly integrated into the desktop? Is wx just really hard to use and every developer screws it up? Does wx use the native widgets correctly but screw up things like padding and highlights? Is the subset of widgets that are supported on every platform too limited, so everyone is forced to use non-native widgets (which apparently always look bad in wx)?
PoEdit comes the closest to looking genuinely native, but the MacOS implementation is clearly flawed.
There are many screenshots here, I'm not sure which one do you mean. But do keep in mind that some of these screenshots (maybe even most of them) are 10, or 20, years old, so what seems non-native to you today might be just the way things used to look.
I really do mean basically every screenshot. But take ECMerge for example. If you switch back and forth between Linux (GTK?) and Win7, you'll see that for example the toolbar is exactly the same color on each. It doesn't integrate with the Windows environment at all. But surely Windows has a native toolbar widget? And possibly even a native icon theme that you could use instead of the GTK icons. And even if not, surely wxWidgets could choose the color of the toolbar based on the desktop theme, and not just fall back to the same default colors?
Or check "Game Develop". The primary interface is a kind of weird rip-off of the MS Office ribbon, but I assume this is a custom widget. There's also a tab interface though, and this doesn't work on either the Windows or GTK versions: it's weird and has a gradient background.
In general, small details like the padding, coloration, and borders drawn around widgets seem to be slightly off on most platforms with just about very wx based GUI I've seen.
ECMerge seems to use standard wxToolBar which is definitely a native control, so I don't know why it has the same background on all the screenshots. Perhaps they've explicitly changed it to make them more similar, I really can't say. But if you create a toolbar out of the box, it will look exactly the same as in any other native application. As for the icons, wx does provide a limited set of stock icons, but this will almost never be enough, so you need to either get high quality icons in the style of each platform you support, which is obviously difficult for an open source/free program, or use the same, typically Linux-style, icons everywhere just because this is what is there, for free.
The rest of the controls (ribbon, tabs) are indeed non-native and there are no native equivalents for them, so there is not much to say here.
Generally speaking, there shouldn't be any problem with the colours unless you change them explicitly, which is a bad idea for the native controls. Not sure what is wrong with the padding and borders.
Sorry, I don't know what is this supposed to prove, but I can definitely assure you that all the mentioned controls, and many others, are exactly native controls under the 3 first tier platforms (MSW, GTK and macOS).
> Do you have any proof?
Proof of absence of something is hard to make, all I can say is that you can go through MSDN, GTK and Cocoa documentation to convince yourself.
It does for the widgets that have no native equivalent, such as draggable/dockable tabs/panels that you show. You can't say they differ from native ones because there is just no native version, on any platform.
OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native and not only they look natively, but also behave natively, which is pretty important and different from Qt.