No, Windows has Qt, Gtk and all the others, too. Virtually any regular user Windows install has 2-5 Qt apps on it. And Windows has been infamous for apps reinventing standard UI elements with skinned monstrosities.
This becomes painfully obvious when you start working with any kind of GUI automation tools (e.g. AutoIt). I imagine users of screenreaders have similar issues.
This is before you get into pro apps like Mathematica or Maya (and half of Autodesk's other apps and Nuke and so on). Or not-pro but widely used and semigeeky stuff like Avidemux. Or Valve's video making tool for Source engine video games like TF2 used by game YouTubers and esports people.
Qt is a pretty common way to write GUI apps for Windows. Just go to any regularly used Windows PC with a 20-something user and I almost guarantee you will find a few qtcore DLLs.
The fact is a user can go for years without ever using one. And in the tens of millions of apps available for Windows, QT based ones make for less than 1/1000...
Yeah, a user can conceivably go for years without using one. By far most won't though, or will have Qt apps installed they don't use frequently.
Qt is an 800k developer ecosystem[1] -- do you think they all work on Wireshark? Most of them write Windows apps.
1 = https://youtu.be/sa2gS9GKG9Y
Edit: windows.com seems quite taken as well: https://blogs.windows.com/devices/2011/03/15/10-qt-use-cases...
Not sure about the "axe to grind" thing -- I didn't call any names, and it kind of calls for people to see any kind of reply from me as further "aggression". I merely stated my opinion based on what I've seen 15+ years in IT (including using QT to write some KDE API based apps).
I believe I have a quite good understanding on where QT stands in the "commercial apps" landscape, and common isn't the word I'd use for it. Skype would be the biggest success story, if they still use it, and it looks quite different from the regular QT/Windows look (which is what we were discussing).
So, just by Skype alone sure, you'll find "most Windows PCs used by regular consumers have [a copy] of Qt on them", but that's not enough to call it common in my book. Most regular PC also have had Java applet SDK and even JREs, and one could cite a few apps using it, but few would call Swing "popular" in the desktop space.
As for Qt being a "800k developer ecosystem", a lot of them work on internal enterprise tools, automation software and stuff like that, which has been a traditional market for TrollTech and QT in past decades. Then there's always KDE of course too.
Many of which run on Windows, FWIW.
In fact, as I've just checked it again to be sure, the whole initial point was a non starter, trying to paint Windows as equally fragmented, UI-wise, as Linux.
- iTunes (built on a port of some of Cocoa I think)
- Spotify (custom UX, also on Linux - using Qt - but I don't bother)
- Steam (custom UX, own toolkit - also on Linux)
- EA Origin (custom UX, made with Qt)
- KakaoTalk (custom UX, I think using a native toolkit though)
- LINE (similar to Kakao)
- Telegram (custom UX, built on Qt - actually this runs fine on Linux, but I keep it in the VM alongside KakaoTalk because it's the same use case)
- Firefox (custom UX, with native-ish theming by its own XUL toolkit grabbing stuff from Windows APIs)
- Chrome (custom UX, built on a custom toolkit called Aura with some Windows exceptions)
- Kodi (custom fullscreen UX)
All of these are apps with user numbers in the range of hundreds of thousands to tens of millions, and they're all unicorns. (You may never have heard of KakaoTalk or LINE, say, but both have 50+ million desktop installed bases.)
Some of the above (Telegram, Firefox, Chrome, Steam, Spotify) show up on Linux just the same, no better or worse. Outside of that, most apps people actually use on Linux:
- KDE/Qt apps, which import a lot of standard structure from kxmlgui and DE settings (e.g. dialog button order, standard dialogs) from Qt's QPA plugins
- Gnome apps, which follow a strongly defined HIG
- Non-Gnome GTK+ apps imitating the Win98-style HIG for the most part (which overlaps a fair bit with the kxmlgui standard structure)
Sure, there's a long tail of other toolkits on Linux (just as on Windows), but my argument is basically: Going by the most-used apps, Windows and Linux suffer this problem (if you consider it one) to a similar degree, but Windows slighly worse because outside the apps showing up on both platforms, the remaining popular Windows apps are more fragmented UX-wise than on Linux with its three broad categories.
Heck, Windows 10's bundled apps are fragmented UI-wise to a much greater degree than any competing offering due to the classic/Metro divide.
It's an utter mess. An interesting question is whether this messyness hasn't had some benefits (like allowing app designers to iterate and innovate individually, with no concern for following a system HIG, allowing the overall platform not to fall behind the curb). But arguing the mess isn't there is very strange to me.
I guess Wireshark's Qt and it gets used occasionally. But most of the cross-platform Qt and GTK stuff I used to install (Pidgin and GIMP immediately come to mind) I haven't even installed on a machine in ages. I've moved to native alternatives for a lot of the stuff I run, and what cross-platform applications I do run (Chrome, Sublime, etc.) tend to implement UIs with the native toolkit, since that's a much better experience on non-Linux platforms.
I'd also argue that Qt applications are still "native" in that they run as a native EXE (or ELF on nix). Granted they don't use Win32 APIs, but then calling them non-native because of that is a little like calling Windows OpenGL games non-native because they don't use Direct3D. But that's an aside point.
On the whole, I don't think it makes sense to categorise Windows desktop applications by what toolkit they use. MS Office 2003 didn't use Win32 toolbars. Office 2007 then introduced the ribbon bar, which changed in appearance in every subsequent release of MS Office. And even within MS Office, Microsoft doesn't always follow the same design patterns (Office 2007 used ribbon in Word and Excel but not in Outlook). Even outside of MS Office, some Windows applications in WinXP used different menu bars to the ones provided by the Win32 APIs (you can see by looking at whether menu items go 3D or just highlight when you hover over them). One example was the difference between Windows Explorer and Notepad. Plus often older Windows utilities go completely unaltered for years, eg the add font dialog box in XP was still using Windows 3.1 APIs: http://apagreekkeys.org/images/addFont1.jpg ....and this is all without discussing the disruption Metro has caused.
I will grant you that in spite of these criticisms, Windows still fairs better than Linux in terms of uniformity. But it's certainly not consistent enough to define anything that doesn't use Win32 widgets as non-native.
You can orchestrate scripts in FP style, similar to the REPLs in Xerox PARC workstations, access any .NET, DLL or COM API as if it was part of Powershell, manipulate data without parsing it all the time, interact with running applications via Windows APIs....
1) You can't write or run scripts "out of the box", you need to do a security incantation first. A oneoff hurdle, but right at the start of the learning curve.
2) Perhaps because of (1), it's not very dogfooded: on a UNIX system, there are lots of already-existing shell scripts sitting around as parts of the OS. PS is not so rich in examples.
3) If you do actually want to parse data, it's not very good at this.
4) I've not worked out how to save intermediate stages in a pipeline to persistent storage.
5) Hasn't yet developed much of a "user culture", although I think that will come eventually.
Not saying that's a bad thing, just that we (as Unix folks) do things intuitively that we forgot we once not intuitive.
Totally agreed on 2 though 5 though.
To me the real superiority of the windows GUI is that almost all of the settings are accessible with a GUI. In Linux or MacOX you very quickly end up having to write some command lines or editing a text file. That's great for already experienced users or administrators running batches. But to the common user, discoverability and intuitiveness is crucial and you are not helping them with an OS they can't understand or control. One should be able to visually see the state of the system.
If CLI had auto-complete/intellisense features, the gap would be smaller.
Hmm ...
(I've been writing Win32 apps for over a decade, so maybe I'm biased that way, but I definitely prefer (ba)sh over command.com/cmd.exe. My ideal environment would be a pre-Metro Windows GUI with a UNIX-based filesystem and command prompt...)