The only thing closeish to a native UI is macOS and iOS AppKit and UIKit. Winforms aka Win32 is still a thing, but Microsoft has been undogfooding that and putting out alternatives for years, now WinUI3 will definitely kill off Winforms for good! What is native on Linux? Gtk, Qt, Motif (lol)?
And then Android? Ironic then that Google is the one behind Flutter.
The concept of native outside of MacOS/iOS is pretty busted at this point. At best it just means something non-web.
Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there. Yes, the same vendor provides other toolkits.
Linux is a kernel project, and different distributions are for many purposes best considered to be different OS's. Desktops based on Linux mostly are either GTK or QT, and so the native toolkit depends on the desktop you are using.
Is this too much fragmentation for users on those platforms to realistically expect commercial software to support them natively? Yes, of course, but that doesn't mean there is any confusion about what it would mean to do so.
Win32 is no longer the native GUI toolkit on Windows, given how much of the OS GUI itself is not using it (new Settings etc). If the argument is that it ships in the box, well, so does UWP XAML.
Is that useful pedantry? From context, you really think that's my confusion here? I didn't include *BSD either, but it isn't any different for the relative handful of people using that for a desktop system.
> Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there.
Except for Microsoft's numerous attempts to supplant it and the fact that the base OS doesn't even use it consistently for their own system. Microsoft's own File Explorer and Settings app that only had to live along with Control Panel for a decade, was that not native? They aren't "Win32".
If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API. Nobody casually calls it USER though, and the bulk of people still targeting it do so through .NET these days via Winforms.
If native just means provided by the vendors base system, ok, but then if there are 10 different forms of it, other than the distribution issue there isn't some great intrinsic benefit over just targeting Qt or Flutter. Especially when someone like Microsoft can't settle on a consistent design language through the years.
> If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API.
I don’t think it is “anachronistic” - as far as I am aware it is still the official name. And I don’t think calling it the “Windows API” is right, since Win32 is just one of the APIs that Windows offers. If I’m calling CreateFile, I’m using the Win32 API, but if I’m calling NtCreateFile, I’m not using the Win32 API, I’m using the native NT API instead. If I set the subsystem as NT instead of Win32 in my executable’s PE header, calls to native NT APIs such as NtCreateFile will still work fine, attempts to use Win32 subsystem APIs won’t. And there are other APIs Windows has which aren’t (strictly speaking) part of either the native NT API or the Win32 API - COM and the many APIs built on top of it, .Net, WinRT, DirectX, etc.
But you are right that Win32 isn’t a GUI toolkit. It contains a rather basic and old-fashioned GUI toolkit (USER), but it contains a lot of non-GUI APIs too. I’m reasonably familiar with those parts of the Win32 API used by services and console mode apps, but if you asked me to write a Win32 GUI event loop I’d be asking ChatGPT to remind me how, because while I’ve read tutorials I’ve never actually attempted it.
The name itself is anachronistic, what does the 32 stand for? You call CreateFile with 64-bit pointers, it was still considered Win32 (until they officially changed it).
"Using the Windows API, you can develop applications that run successfully on all versions of Windows while taking advantage of the features and capabilities unique to each version. (Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)"
The API provided by ntdll is semi-officially called the "Native" API and much of it is subsumed into the Windows API. The PE subsystem names you are referring to are IMAGE_SUBSYSTEM_NATIVE and IMAGE_SUBSYSTEM_WINDOWS_GUI/CUI, so it's somewhat consistent.
Microsoft officially refers to that API as Native System Services in the documentation for the DDK.
Microsoft’s docs are a self-contradictory tangled incomplete and sometimes even downright erroneous mess, I wouldn’t put too much stock in what they say.
If I say “CreateFile is the Win32 API analog of NtCreateFile in the NT native API”, everyone experienced with low-level Windows development will know what I am talking about. If I started talking about “Native System Services”, I’m not sure as many would.
Similarly, the distinction between APIs which are easy to call from C code (and simpler FFI frameworks from scripting languages, e.g. libffi) and COM/Automation/.Net/WinRT APIs which are a lot more difficult to use from C (as opposed to C++), and which require more advanced FFI support, is still important in Windows development (or at least some parts of it.) And in practice the term “Win32 API” is often defined to exclude those higher-level harder-to-call-from-plain-old-C APIs.
It goes back to the original design of Windows NT, where you had a primary environment subsystem (Win32), secondary environment subsystems (OS/2 and POSIX), and integral subsystems (local security authority, session manager, etc). The primary environment subsystem is still called Win32, and the Win32 API is its public API. (It also has private APIs, most notably the CSRSS LPC interface, but that’s unstable from version to version.). As I said “Windows API” is insufficiently specific because (especially nowadays) Windows has lots of other APIs. WinRT and Win32 are both Windows APIs but very different. WinRT is largely built on top of Win32, but some documented WinRT APIs are built on undocumented Win32 APIs, leaving WinRT the only officially supported API to access certain functions.
Microsoft intentionally didn’t rename Win32 to Win64 when they added 64-bit support because it is 99% the same API just with some highly regular changes (mainly widening pointers). By contrast, Win32 was a much more radical change to Win16 - the Win16 API directly incorporates notions of segmented memory, which it uses to implement movable memory blocks (rather similar to Classic MacOS, albeit that did it in a 24/32-bit flat memory model rather than a 16-bit segmented one). Microsoft could have done a more straightforward port of Win16 to 32-bit x86, e.g. using a 32-bit segmented memory model instead of 32-bit flat memory, keeping movable memory; but (thankfully) they didn’t. It would have made it a lot harder to move to 64-bit or non-x86 platforms.
GTK 3 or 4? Xfce+MATE+Cinnamon are still popular enough options and I used the former for years.
GTK itself isn't even a well defined target.
And GTK3 apps of which there are plenty do not appear native in a modern GNOME desktop much more so than a decent Qt app does.
The thing is that people in the real world talk about Linux support for an app, as in Desktop Linux support, and the only common denominator there for years was basically X11. I have heard exactly no one ever ask, oh when is that app going to be available for KDE or GNOME. For example, to take something recent here, do the people writing the Zed editor promise a particular DE support - no it's available for "Linux."
As to earlier mentioning distros - for a GUI app, there’s more pain from intra-distro variation than inter-distro, both across configurations and supported versions.
Now the big thing, the even bigger thing is probably native Wayland vs X11, but no one says, oh vendor will you please bring your app to KDE or GNOME, specifically. 99% of the time you are happy if you get anything at all.
So the concept of native on Linux (Desktop Linux) just isn't something usually worth discussing.
Linux is not something that encompasses a GUI, so this is a misguided way to frame the underlying concern. One might as well ask what toolkit is native on smartphones, or what language is natively spoken by humans.
We should instead ask what is native on Plasma, or on GNOME.
"Oh, bother. That would mean I have to think of four things instead of three."
Well, yes, Pooh. But the things that make them different are the things that make them, them.
"Just build native UIs. I don't know why cross platform UI has been such a hobbyhorse for so many for so long: it's a stupid idea."
The stupid idea is thinking that building native UIs is targeting a clean, non-moving target and implying it is not astronomically harder than doing something cross platform that is between mediocre and good enough for everybody.
Whenever someone says “just do native” it always turns out they have a cockamamie definition of native, otherwise they would realize the gravity and general unreasonableness of what they were asking.
On a side note, what’s a major* reasonably complex app that isn’t a music player or an IRC client, or something with a simple shell around a canvas like a browser, that targets both Plasma and GNOME natively.
* And whether anyone likes it or not, few people care (as revealed by $$, not bitching on a forum). Blame electron, the web, but even Microsoft cannot even define and maintain a native LnF for their core operating system. As I alluded to, the only small community that cares are those on MacOS and iOS, where there is a HIG that more than 2 people have read and give a shit about, and there is a small market of people that value well integrated Mac apps that will actually spend money.
Targeting Win USER32 +/- XAML, Qt, GTK, and AppKit is costly and thankless when you probably could have just used Qt, JavaFX, or Flutter, etc.
So that means one has to target both GTK and Qt to be native on Linux. Fat chance of that on anything but yet another music player or other relatively trivial UI app.
In any event, that still doesn't answer what it means to be "native"? And my point is I think most definitions are dumb or useless.
If I'm running a GTK desktop, Qt apps are generally not "native" no matter how much theme fuckery one tries. Native can also speak to other common UI affordances and design guidelines, and there sure as hell is nothing like there is in the MacOS world for linux. Some core GNOME and KDE desktop apps maybe, but overall there isn't much adopted standardization in Linux world.
90% of the work I get done involving a GUI outside a browser on Linux usually involves Java, whether it be Intellij, ghidra, etc. Maybe I'll pick up blender from time to time. Audacity, there's a good one, targeting (for now) a cross-platform toolkit that pretends you can have your cake and eat it too - wxWidgets never fooled anyone - they sure as hell don't look native on MacOS, and they invariably look much closer to what they riffed off of, a 90s MFC app. (And wxWidgets wraps GTK and AppKit, so is it native? If so, native is meaningless IMHO. If not, why not?)
> So that means one has to target both GTK and Qt to be native on Linux.
Doesn't it mean that you can target _either_ and be considered native?
Also, I'm not sure I buy the claim that of "GTK and Qt are native" in the first place. I'd say either that there is no native UI, or if I must call something native, it's the toolkit the desktop environment uses. And yes, that does mean that there is no "Linux nativeness" like there is Windows nativeness, as every DE is different. And rightly so, because one could in principle write a different DE over the Windows kernel, whose UI would behave differently.
> Doesn't it mean that you can target _either_ and be considered native?
Well, no because I was agreeing with you, if you're going to grudgingly accept your definition for native, the toolkit the desktop environment uses, that means you would have to target both Qt and GTK unless you want to draw a line in the sand and say fuck it to one of GNOME or KDE as assume they don't exist. Sorry GNUStep. And this is nothing to say of GTK 2-4.
I agree that just saying GTK or Qt are native in a vacuum outside of DE is a completely useless definition, and even taking DE into account is a tenuous one.
As for Windows, what GUI toolkit does the desktop environment there use? That's a trick question.
How is Qt within a GNOME or Xfce environment any more "native" than Qt on Windows or Mac?
You have reduced the definition of "native" to merely compatible with X11/Wayland (that's the only common denominator). Well now, Tk, FLTK, Swing, and even Wine are all native.
Both Qt and GTK have facilities for integrating into each other’s desktop environments (see [1]). Sometimes they blend in nicely, sometimes they stand out a bit, but I think it works out pretty okay.
GTK doesn't much care about integrating into a Qt environment and doesn't really implement anything to make that work besides in some cases implementing the same Freedesktop standards. Even for basic things like the look of widgets you need a style that has implementations for GTK - there is no compatibility layer to use Qt styles. Gnomies in general don't care about anything outside their world.
The other way around is a bit better, e.g. there is QGtkStyle but AFAIK it is stuck at GTK2 and does not support using GTK3 styles. Still, behavior between GTK and Qt applications is very noticeably different.
It would be great if there was a shared ABI applications could use but GUI toolkits are too complicated for this to be feasible.
> Both Qt and GTK have facilities for integrating into each other’s desktop environments
Neither Qt nor GTK are desktop environments and Qt certainly isn’t defined by a dominant desktop environment - KDE isn’t even what pays their bills.
You’re still proving my point. The common denominator here (on Linux) is just X11/Wayland. If it works out “pretty okay”, then score one for a cross platform toolkit. Still no idea what über alles “native” means.
Let’s go back to the original comment I responded to… why should I not just continue with the Qt “stupid” “hobbyhorse”
You missed the sarcasm. If all can exist together, which one is the “native” one? If the answer is all of the above, then the consistency argument for native doesn’t hold much water.
Do you see any reasons why many companies/teams/devs don't want to "just build native UIs" and instead are looking for cross-platform solutions designed from ground apps for modern UI development needs?
Yeah I do see why they don't want to do it and I see it as a critical failure of risk management.
If you think pinning your entire product on a cross platform UI kit when every single one (except maybe QT) had proven a failure... then yeah I think maybe you should consider actually just eating the cost of building native UIs.
The risk analysis of building against supposed cross platform "solutions" just doesn't work out. Why do we keep trying to do it?
The idea of cross platform UI is frankly "f*cked from the jump" and should never have been a goal. I think it's only a goal because it's intellectually satisfying, not because it's really desirable.
Cool, none of that is remotely relevant to what we are talking about here.
Your anecdotes are dated and you should think about updating them so you don’t talk so confidently on things you don’t actually seem to know much about.
I mean that sincerely not as some internet gotcha there’s just no need to sit there defending a position that is based on old info just for the sake of it.
As someone desperately fighting to keep their company's main product to stay using a native desktop UI, Microsoft makes it real hard. WinUI3 hasn't even officially launched and it already feels like it's on life support. QT is good, but even qt seems to be starting to use a web renderer.
It's really something I know nothing about so I googled WinUI3 and the 3 first results are microsoft website and github, and the next two are "is winui3 dead ?" and "Oh winui3 is really" dead. So it doesn't inspire confidence :)
I suppose it was incorrect of me to say it hasn't "officially" launched then. But one would certainly seem to get that impression, considering it's missing major features (data table support?) isn't anywhere near feature parity with either WPF or winforms, and doesn't even have a visual editor (which should be table stakes for a modern 1.0 release from a company as large as Microsoft).
It's just not that good?
Just build native UIs. I don't know why cross platform UI has been such a hobbyhorse for so many for so long: it's a stupid idea.