Slashdot Mirror
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.
Check out this list of mostly obscure and unknown software that uses Qt.
Most software is obscure, full-stop. Just because you don't use most (or even any) of the packages on that page doesn't mean that Qt isn't a viable mainstream library, or that there's anything wrong with it.
Qt, like any other large framework, has a learning curve. If you're writing an application that works just fine using whatever libraries you're already using and you're only targeting one OS, then you probably aren't motivated to go climb that mountain. On the other hand if you're writing software (possibly with a complex UI) that is intended to target multiple operating systems, then Qt is probably the single best framework out there for doing so. Otherwise you're in for a long haul of writing your own less functional version of some subset of Qt features in order to abstract platform specific code away from the rest of your application functionality.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
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.
Just to add to QRDeNameland answer... GCompris switched from GTK to Qt. Thousands (millions?) of users. AutoDesk's Maya is using Qt. Thousands of users (professionals and non-professionals). WorkNC is using Qt. Thousands of professional users. Seems pretty mainstream.
A) it's not a "little language," it's an API - just like every other major development environment.
B) good APIs (including Qt) are not "little," they're more extensive than the language they're implemented in.
C) The major complaint I hear leveled at Qt/KDE et. al. is that they're "bloated" - they run the meta-object compiler (little language) first and then compile all that plus your code in C++ and the resulting product is "bloated." Well, if you're trying to target $3 ST-Micro chips, it may be a bit bloated, but if you can afford at least a Raspberry Pi for your execution platform, Qt fits and runs just fine. "Big" projects (10Kloc) recompile after a full clean on my 3 year old laptop in 15 seconds or less.
D) I get to compare/contrast the Qt/Creator dev environment with Microsoft C#/Visual Studio daily. Compared to Studio, Creator is freakin' light weight, lightning fast and compact. Back c2010, Creator was "ahead" of Visual Studio as a developer friendly environment to work in, with Studio only really better in the debugger department. Today's Creator debugger beats Studio's 2010 debugger, but MS has invested a lot in Studio lately, and it shows - it's great when it's working, but bloat doesn't even begin to describe the developer experience for Visual Studio installation and updates.
Q) haters gonna hate.