There's also a large repository of software that isn't switching. "Won" implies the war is over; that Qt has earned a monopoly on Linux (or at least the de facto standard) but that's not the case here. At least not yet, maybe in a few years - though I can't see that either personally.
Maybe I'm just being pedantic, but "won" seems a little too optimistic. Particularly on a platform that's famed for it choice / fragmentation (depending on which side of the fence you sit hehe).
It also implies that there was actually a war, and that there is now not. Did gtk+ suddenly stop being developed because Qt won some imaginary war dreamed up by people who don't develop either toolkit?
Wow, I didn't expect people would read so much in my poetic language.
Qt used to be relegated to KDE on Unix but is now also used by Unity and LXDE. People prefer using Qt because it is much more cross platform friendly than GTK+ and has great developer tools. Qt seems to be the future of the Linux desktop at this point. So excusez-les-mots.
It really, really did not. GTK+ these days is superior to Qt in some critical areas, such as HiDPI support. Lots and lots of new applications and platforms are being written in GTK, consciously choosing it over Qt.
That is by no means an accurate statement. GTK's HiDPI support involves an integer scaling factor for the whole desktop, and that's it.
Qt/KDE on the other hand allows you to simply specify the size and dpi of your display and everything will scale accurately, aided by the fact that KDE uses SVG icons.
You're conflating a desktop environment and a graphics toolkit. KDE <-> GTK+ ~= apples <-> oranges.
Futhermore, no, GTK's HiDPI support does not in fact force a scaling factor for the whole desktop. You can turn it on app-by-app. The fact that whatever desktop you're using doesn't utilize this capability isn't GTK+'s fault, it's the desktop environment's fault.
Now having said this, you could be entirely correct that for the time being KDE offers a better HiDPI experience than a GTK+-based desktop, but again, that has really nothing to do with the toolkits themselves.
Subsurface, a program for divers, was another high-profile switch. High profile because Linus started it. If he and a bunch of other pretty smart kernel hackers can't figure out GTK, that says something.
"Subsurface, a program for divers, was another high-profile switch"
I can't see how subsurface, which is an extremely niche application, can be considered as high-profile. And I am a scuba diver myself, so I have a bias going opposite what my opinion here is.
" If he and a bunch ... can't figure out GTK, that says something"
All it says is that they like Qt better. Linus told at a Debian meeting that he does not use Ubuntu or Debian because he tried once to install it and it did not work for his hardware, while some other distro worked right away. He never tried it again since. Does it mean that Debian is crap because if even Linus cannot figure it out "it says something"? No, of course not.
Which is a drop in the ocean as far as the FOSS app ecosystem go, and to be honest after all this time I can't see either of GTK or Qt winning the 'toolkit war'.
If either of those would have the capacity to emerge as the de facto standard then it would have happened long time ago in my opinion.
Taking a quick look at the gui software (not a whole lot as I typically prefer the commandline) I have on my Linux desktop machine (running bspwm, not a desktop environment):
Of course this is purely anecdotal, but this notion of some 'winner' in the FOSS toolkit space comes across as fanboyism more than anything based in reality.
I'm not citing Qt software I use, I'm citing GTK software that is now switching toolkits. How many apps are going from Qt to GTK? I could write a list of KDE equivalents to all the GTK programs you are citing - nobody is arguing that there isn't pretty much a program for every use case written against either toolkit. The question is what is software people are using, and what toolkit are people looking to write new software using? Conclusively it seems to be Qt nowadays.
It's irrelevant how many apps are switching, given that Qt have for so many years been a total non-starter for a huge segment of Linux desktop apps. As you say, the question is what software people are using, and you've given nothing real to support your contention that this "conclusively seems to be Qt nowadays".
Qt is not even standard C++ . I can't understand how people are double standard'ed and double dealing with problems . just look at what is done by Qt in C++ (whole non-standard Moc's) I am sure if it was from Microsoft (even open source product) whole Internet blaming Microsoft "wtf is this" & "Microsoft every time should disobey standards" and "Microsoft is just crap". how is this work? when we (as open source community) doing something this is good , but If Microsoft done something exactly like this then Microsoft is evil.
Sorry but that's an old, tired argument that only occasionally gets aired these days. Running a pre-processor as part of the build process does not mean that Qt is not standard C++. Also, if you knew anything about the history of Microsoft you'd know they deserve all the stick they get for their abuse of standards - 'embrace and extend' was their philosophy, it sounds innocuous but the effects weren't.
They use a code generator to implement reflection methods on classes marked with the Q_OBJECT macro. The output of that code generator is standard, readable C++. It was, and still is, a very useful, practical way of doing things.
I can't say as to what Microsoft has done or not done, but I don't see anything immoral about the moc.
Another thing I forget to tell , Imagine one day whole linux desktop ported to Qt , what about C programmer ? what is Qt's answer for C programmer ? (please don't start C vs C++ , it is personal and technical choice , somebody like me prefer C's simple approach , somebody maybe like you prefer all OOP/C++ approach)
