#include <QLabel>
#include <QApplication>
int main(int argc, char** argv)
{
QApplication app{argc, argv};
QLabel label{"hello world!"};
label.show();
return app.exec();
}
$ g++ -O2 -g0 -fPIC hello.cpp -I/usr/include/qt -I/usr/include/qt/QtWidgets -lQt5Widgets -lQt5Core
$ du -csh a.out
16K a.out
So nice to see people fabricating numbers and passing them off as data.
The mechanisms are still there but the practice died when Qt stopped focusing on embedded targets.
http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-pr...
Embedded is the biggest market for Qt right now.
1) Qt Widgets development stopped with 5.0. I had bugs filed on the embedded Linux targets and was told "sorry, these will never be fixed".
2) #1 means that Qt wants you to use QML. I need to run a Javascript engine on my target? Note in the comments of that blog post that they hope to run on an A7 (or really fast M7)...someday.
2b) ...And if they do run on a lower end platform, you still need a POSIX O/S. uCLinux is not a great option on M3/M4 CPUs and keeping the binding dynamic on those cores to stay LGPL compliant is extremely difficult.
3) QML bindings are a pain in the ass, especially when you're trying to put a UI on legacy code.
4) Most crucial: Qt Lite and QtDC are commercial products only.
So, in my opinion, embedded is still a 2nd class player. Or, I could clarify further: low end embedded is a 2nd class player. If you're working on automotive HMI/IVI? They'd love your business.
Web-apps are architected fundamentally different than classical software.
That's not why these demos "Hello Framework" demos are 3-7MB though. That's due to the cost of shipping an entire widget system that takes complete responsibility for everything between raw user input to pixels on the screen, without using many of the affordances of browser APIs. This is really awesome for emulation, sandboxing, and preservation of software, but it's not a good route for saving bytes for the user.