That's the main idea of wxWidgets - it doesn't have its own GUI backend (wxUniversal really doesn't count) but uses other native frameworks such as win32, cocoa gtk and now QT too. So it will probably look nice and native in say KDE environment.
That's absolute nonsense. First of all there's no "native" platform to Qt because it's cross-platform, and that's taken extremely seriously. Second of all, Qt apps are extremely well integrated on Windows, OSX and Linux alike.
There's tons of examples of commercial Qt apps exactly for that reason. What you say is true only for GTK, not Qt.
Disclaimer: Lead dev/designer of LXQt.
>On some platforms (such as MeeGo and KDE) Qt is the native API. Some other portable graphical toolkits have made different design decisions; for example, wxWidgets uses the toolkits of the target platform for its implementations.
As far as I know, it's also true that Qt doesn't try to use native widgets, it instead tries to draw them on its own (resulting in more possibilities of course).
So much so, in fact, that the title of their webpage is: "KDE - The KDE development platform".
I should know, I've been following (and occasionally participating) in the project since 1998.
Like you said, KDE leverages Qt. Qt doesn't leverage KDE in the sense that "Qt's native platform is KDE".
When you say "native" when talking about a cross-platform toolkit, you're implying the toolkit was first designed to run on that platform and then ported to others. Qt predates KDE, as you well know.
Are we done splitting hairs?
No, you're just implying (as the parent did) that the platform (KDE) had picked and stuck to the toolkit (Qt) as its basis, unlike Wx which has multiple.
I've never seen a QT app that I couldn't immediately tell apart from a native OS X/Cocoa app -- with the exception of Skype, which still doesn't look 100% native, but at least looks like it has a decent skin.
They have different OS X (Cocoa/Obj-C), QT and even GTK implementation of the UI.
It's not subtle either, these things always stick like sore thumbs -- only exception are some that only use very basic widgets and delegate 90% of the work to native ones (like native file open dialogs etc).
But let's see, if you have any
Qt looks pretty close if you stick to just the essential controls/widgets (text, buttons, text fields). Once you start using other stuff you can definitely tell it isn't a native application. That's not to say Qt isn't good. It's a great toolkit and far, far more complete and featureful than wxWidgets but that's comes as a trade off. The native-backed nature of wxWidgets means you are kind of working with the lowest common denominator a lot of the time which means you don't often get more sophisticated control/widget options. You also have to deal with more bugs between the platforms whereas you rarely have to with Qt.
You have to decide if you want a big, powerful toolkit with commercial backing (and a pretty hefty licensing fee for commercial users) that doesn't quite feel native or a natively-backed toolkit that is less featureful, more buggy, and free.
But compared to what? A ribbon app like MSWord? Photoshop? VS2015? VS200X? They're all radically different and they're all creation-centered apps, so if you tell me Qt Creator doesn't feel native... it feels more native than any of those I cited, all massive commercial successes?
It's like you said... it looks native when you stick to forms and buttons. And honestly, yeah that's fine, because any app that doesn't stick to forms and buttons will want to customize itself far more.
You usually cannot tell wxWidgets application from any other system one (unless the developer is clueless about platform guidelines like Quit menu item on Mac or such).
Gimp created its own toolkit because at the time, Qt didn't have a GPL-compatible license.
While it is a great apps, UI-wise it is exactly as masklinn wrote. It has weirdness-es on all - Windows, OSX and Linux.