|
First off, Qt is native for quite a few Linux GUI desktops. So there's no "port" for those. But even beyond that, the toolkit you're referring to (QtWidgets) is only one part of Qt itself. In fact I rather doubt you'd ever use it for an Android application, preferring instead QtCore plus the declarative U/I handling. Much of Qt is code you would otherwise be writing /anyways/, only they did it for you, did it right, and even documented it with examples of how to use properly. For instance, event loops, abstract I/O, Unicode string handling, concurrency, atomics primitives, networking support (including integration into aforementioned event loops and abstract I/O), and much more. As a side effect of coding to a thoughtful, high-level API you happen to make cross-platform development easier, but that's hardly the only reason to use Qt. Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize... |
That's because Linux has no "native" GUI. It's a hodgepodge of GUI toolkits.
That said, the de facto standard on Linux desktop has been GTK. It's what the major players, that is the most popular distros, support by default.
So QT is only "native" (in the look & feel sense that we're discussing here, not in the runs directly on the machine sense) if you target some marginal distros. Which kind of defeats the whole argument.
>Much of Qt is code you would otherwise be writing /anyways/
Not if you used Google's native SDK.
>Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize...
Huh? Who said you don't recognize them? On the Mac they stick out like a sore thumb.