So this is where I'd start[0]. Their site has amazing documentation. I personally found Qt even in the KDE2 days miles better than React/Redux and non-Smalltal

So this is where I'd start[0]. Their site has amazing documentation. I personally found Qt even in the KDE2 days miles better than React/Redux and non-Smalltalk MVC's. Since then it's only gotten better. Check out the examples here[1], the diving in section here[2], the book here[3], Stackoverflow has an overview of the whole system here[4]. You emit signals. Slots consume them. QObject::connect links the two. Queues are just queues in the traditional MQ sense. You don't use them in for, say, local GUI controls since it's generally a 1-1 unidirectional link (and if it's bi-directional, although I rarely need to do this, just ::connect( a,b,SLOT(),SIGNAL() ) then ::connect( b,a,SLOT(),SIGNAL() ). If you're still having problems read this[5]. If you have issues, that blog also has a preceding page which has a comprehensive analysis of the underpinnings of the entire slot/signal system in QT. If you still have problems, get on IRC and someone will give you a hand. If you're having a major issue, contact me. If it's a quicky I'll lend a hand, if not I know a few absolutely spectacular HN engineers who I'd recommend in a heartbeat. I'd be real curious as to what's you consider 'messy' about signals/slots is you're having re: slots/signals (I guess since I've used Moose's MOP with Perl 5 and CL they sort of came naturally to me). I have no affiliation with Trolltech/QT/Nokia/whoever-owns-whatever-now at all; I just think C++ is real easy to mess up, libraries are even easier and they did a way-above-average job with their code-base (not to mention, documentation, ecosystem, etc). The setup you want to use for cross-platform is Qt5.x + QML 2.x + QtQuick 2.x (aka QtQuickControls 2 in newer versions). There's licensing issues on some of the fancy-schmancy widgets but most of the things follow LGPL, so just dynamically link, follow the rules, and you won't get sued. If you're working on a legacy codebase (gcc2.95.3 hollaaaaa), don't try to force new-style QT into an old project, or your experience will be similar to @bwoj. 5.6(or there abouts) and up is where QML started to shine. N.b. you don't have to use QTcreator. I find it satisfactory but that just might be years of Stockholm Syndrome. Most people coming from the C++/MFC (or C++/WTL/ATL/COM/WinAPI world) are more comfortable with Visual Studio. No problem, the 'standard' procedure is just to do what you would do with any .sln and split GUI into another project. ---- [0] https://www.qt.io/qt-essentials-qt-quick-for-c-developers/ https://www.qt.io/qt-essentials-qt-quick-for-c-developers/ [1] http://doc.qt.io/qt-5/qtquick-codesamples.html http://doc.qt.io/qt-5/qtquick-codesamples.html [2] http://doc.qt.io/qt-5/qmlapplications.html http://doc.qt.io/qt-5/qmlapplications.html [3] https://qmlbook.github.io/assets/qt5_cadaques.pdf https://qmlbook.github.io/assets/qt5_cadaques.pdf [4] http://stackoverflow.com/a/19837895 http://stackoverflow.com/a/19837895 [5] https://woboq.com/blog/how-qt-signals-slots-work-part2-qt5.html https://woboq.com/blog/how-qt-signals-slots-work-part2-qt5.h...