Is Qt considered native when you use KDE and not native when you use GNOME? Is Qt 3 considered not native when you use a KDE release that uses Qt 4 under the hood?

I would say so. Just like GTK is native on GNOME but definitely not on Windows. "native" (to me) really just means whatever the system is designed for.

Then Windows 10 apparently lacks a native GUI toolkit, because it's certainly not "designed for" just one.

A similar thing happened to Android.

> Then Windows 10 apparently lacks a native GUI toolkit, because it's certainly not "designed for" just one.

Windows 10 has several native GUI toolkits. The same thing happened in MacOS, which transitioned from Carbon to Cocoa.

If the widgets are drawn by a toolkit that isn't bundled with the OS, it's a non-native GUI. Of course, this isn't always a bad move.

One could argue Win32 is still the de-facto GUI toolkit in Win10. Things like .NET Windows Forms and (non-WinUI3) UWP are actually rendered with Win32 common controls.

WIN32 isn't de facto it is the canonical API for Windows. It always has been, since like the 1980's.

Indeed, but with some exceptions. .NET SWF shipped with extremely kludgy drawn clones of toolbars and menu bars instead of using the native ones (although the native ones were later exposed) and the result is that those particular controls on SWF apps did not age gracefully (DPI problems, system theme mismatch, scroll acceleration issues, etc). That’s the kind of thing Qt would also face with drawn components skinned to look like the real deal.

Native usually means standard or specific to the particular system. I would say yes to those questions.

Real question, what do some people mean with native C++? Or stuff like react native? Seems like it just equals more performance / peels away an abstract layer.

Part of the point of "native" is that each platform gets its own consistent look and feel and behavior for its own UI widgets. Back when I worked at Adobe, we had our own internal cross-platform UI framework for Illustrator/Photoshop and they were consistent across the supported platforms, but they didn't look like "native" controls, and that can end up being a pretty big headache (e.g. when accessibility and keyboard navigation don't just automatically work the way the native controls do, that's your problem to fix or punt). They also just generally look "different" and a lot of people consider that a bad thing.

React Native does extend from platform UI components such as UIView, so that one at least is uncontroversially “native”.

Yeah but Qt does it well enough that I consider it de facto native. It's not like Swing Java where they totally went their own way with the widgets.

Nativeness lies more in behavior than in looks. E.g. an input (an edit for old folks) has a very specific popup menu on every system, text selection works in a specific way (think what happens when you double/triple click, move with ctrl or lose or gain focus). Tab order and focusability is important as well. If they get that correctly, by e.g. using borderless system text areas or grabbing a menu from common control internals, it’s not a big deal if they draw some borders or animations by themselves. It’s just pixels in the end, sometimes better than native (which is just crap too often, like windows tables, lists, popdown controls).

But really, native look and feel only left on macOS. Windows lost its traditions around vista, linux never ever had one true way to do UI, and browsers almost exterminated everything else.

Swings Platform LaF was still much closer than current browsers ever get.