Please, I beg of you, do not create an iOS app using this library. Look at that screenshot: https://github.com/therecipe/qt/blob/master/internal/screens...
It looks like a tiny Windows 95 on your phone. Tap targets way too small.
It looks like a tiny Windows 95 on your phone. Tap targets way too small.
[1] https://itunes.apple.com/de/app/auto-motor-und-sport/id36644... [2] https://itunes.apple.com/us/app/mens-health-fitness-trainer/...
These days I use XFCE with http://www.noobslab.com/2016/03/vivacious-colors-gtk-theme-s... and it's nice.
This fragmentation is frustrating sometimes, but in the end what counts is whether the framework has solutions to your problems, and it usually does. (Meanwhile, Qt Quick is improving on the desktop over time.)
I was much more productive and I had much better integration with the respective OS APIs.
Granted, I wish I didn't have to use JS with it, but QML itself is fantastic.
I personally much prefer QtQuick to QtWidgets, and really like the QML declarative language as a better HTML/CSS for non-web. But I completely agree with you that I would prefer if I could code all my logic in C++ and not JS.
I've been meaning to play around with two ideas:
1. Construct the QtQick widget scenegraph wholly from C++ (and not using QML/JS at all). Doable, but definitely not intended usecase.
2. Construct the scenegraph using QML, but using it only for setting values (and never any logic) and then manually connecting the signals from the QML-created widgets to C++ slots.
Even more so if you're running on iOS where the JS isn't jitted.
It's really easy to write QObjects that are accessible to QML and you can connect your signals/slots with the QML widget ones, so having the logic in C++ isn't hard. It's just not quite as convenient as putting it inline in QML, I guess.
They're easy to use, themeable and hardware accelerated.