QtCon Opens In Berlin (qtcon.org)
Long-time Slashdot reader JRiddell writes: A unique coming together of open source communities is happening in Berlin over the next week. QtCon brings together KDE, Qt, VLC and FSF-E to discuss free software, open development, community management and proprietary coding. Live streams of many of the talks are available now. The opening keynote spoke of open data and collaborative coding freeing accessibility information. 13 tracks of talks cover Community, Web, Best practices, Automotive, Mobile and Embedded, Let's talk business, Tooling, QtQuick, Multithreading, OpenGL and 3D.
Software which I use that uses QT: 4K Video Downloader, Calibre, Google Earth, KeePass, MuseScore, PokerTH, Stellarium, Virtual Box, QBittorrent (not on list).
Software that uses QT which I don't use but I believe is pretty popular: Adobe Photoshop Album, Doxygen, Guitar Pro, last.fm, Parallels, Spotify, Wireshark. That's not counting games or dev tools.
Considering that I'd be hard-pressed to list that many useful desktop apps in, for instance, Java, I'd say it's a reasonably impressive list.
Momentarily, the need for the construction of new light will no longer exist.
It's not C++
Qt requires a C++ compiler, it uses classes, namespaces, templates... looks like C++.
they have their own little language that compiles to C++ using an external compiler
False. If you're refering about "moc", it just provides implementations for functions declared through various macros (Q_OBJECT, Q_PROPERTY...). If you use their meta-make (qmake) or some other Qt-aware tool (CMake, VisualStudio with Qt plugins, ...) this is mostly transparent. No "little language" here.
It has crappy alternatives for everything in STL that work just slightly different but not any better.
Qt supports a wide range of C++ compilers since 20 years, including some which were not quite standard conformant or were not providing a "good enough" STL. So Qt provided its own containers. But their use is required only when use some Qt APIs: you can freely and happily use STL containers everywhere else. In more recent versions, Qt's containers provide an API (alongside the Qt one) pretty similar to STL's one. Also they're often seen as easier to use by C++ beginners or non-expert.
It has copy-on-write.
Copy-on-write was very interesting at some point in time. As everything, it's not perfect, but in some cases it was very handy, for example allowing to return large objects by value, allowing great speedup for compilers not knowing about RVO (Return Value Optimisatin). Today it is probably superseded by the move semantic, but this is a rather recent improvement to C++ and maybe not yet supported by all compilers that Qt supports.
It doesn't use inheritance, but gives you endless lists of almost-identical function calls (all those functions to add controls, for example).
Look at the hierarchy of classes inheriting from QObject, look at all the virtual functions that can be overloaded by the user. Inheritance is actually used at large. And most of the "almost identical functions" are there for a purpose.
And that stupid Q everywhere you look is just painful.
Totally subjective and mostly irrelevent. What about those "stupid" gl/GL_ prefixes in OpenGL, vk/VK_ in Vulkan, the "G" in GTK, the "C" for all MFC classes (as if we didn't know already we were dealing with classes), and so on. Of course Qt is not perfect - no one is saying that. Using it daily in a millions-lines (commercial, expensive, closed-source) project, I have my share of gripes against it. But it's the same with any framework. After having used various frameworks in non-trivial projects (GTK+, wxWidget, MFC and a handful of others), for C++ I see Qt as "the best" framework - which in some cases means "the least bad", and never means it's perfect.