[volomike1]

I agree that Qt widgets is obsolete with the market -- they're not keeping up with the latest developments in interfaces and should just abandon this.

My question to you is why bother with QtQuick when you can build your interface in Webkit/HTML/CSS/jQuery? With the Webkit angle, then you can integrate file:// and remote content, and can utilize the best interfaces that the web has to offer, which is innovating far faster than QtQuick could ever dream of innovating because there are more web UI coders than there are QtQuick coders. The other great thing with the Webkit approach is that you can hire lower-cost UI coders (who have no background in C++) to do your interface, and debug it using Chrome. The interface would show up in the upper left-hand corner of the browser. They could stub it all out with fake data and get it working completely, and then pass it to you to do the jQuery connectivity to the Qt/C++ DOM injection so that jQuery could call C++ and get results.

However, if installer size is a concern, then yes, QtQuick is the way to go.

[steaminghacker]

Good question. maybe i don't know the answer. I've been impressed by the way that QML and C++ integrate. I write bits of UI glue JS in QML and these bits call into C++ "magically". I can pass data in and get data back.

This is a lot easier than my JNI battles with Android Java.

I tend to have a lot of backend C++, which performs all the heavy lifting of my apps. I like to make the front UI as thin as possible. QML lets me build things quite fast and i like the way that properties update themselves.

The only real complaint i have with QtQuick/QML is things not working properly on Android. But I'm hoping this situation will improve, and the main reason I'm looking into Controls.2

You say that jquery can call to C++. Where can i find out about this and how would this work on Android.

[volomike1]

> You say that jquery can call to C++. Where can I find out about this and how would this work on Android?

If you use Qt 4.8, which required that you use Qt Webkit, then you're looking at needing to use the QtWebkit Bridge: http://doc.qt.io/qt-4.8/qtwebkit-bridge.html

If you're using Qt 5.7, which also requires that you use Qt WebEngine, then you're looking at needing to use QWebChannel: http://doc.qt.io/qt-5/qwebchannel.html

They allow you to take a QObject class and then share it with the Webkit DOM as a Javascript object. You can then use Javascript and jQuery to call class methods (only ones you expose) of your Qt/C++ QObject class.

BTW, outside of Qt/C++, on the Mac with Objective C, they provide a way to map the AppDelegate to the Webkit DOM using the windowScriptObject, and ObjC lets you use the native Webkit SDK, rather than having to ship another one with your project.

This is great for desktop applications. Unfortunately for iOS and Android, however, both Qt 4.8's Qt Webkit and Qt 5.7's Qt WebEngine are not supported on those mobile platforms. http://stackoverflow.com/a/30662323/105539 I guess on those, you're stuck with using QtQuick/QML interacting with jQuery and C++, I guess? EDIT: On Android and iOS, you can use Qt WebView within a QML application, which uses the native Webkit on each OS. http://doc.qt.io/qt-5/qtwebview-index.html

If I were to develop for iOS and Android, I'd probably use Apache Cordova until something better comes along: https://en.wikipedia.org/wiki/Apache_Cordova#Supported_platf... . One criticism is that Cordova may be slow in some actions, but phones are getting much faster in every release, negating this trouble.

[steaminghacker]

thanks for this info. i'll checkout WebView, see what it can do.

[defiancedigital]

If you have never taste the limit of Webkit/HTML/CSS/jQuery for client side application, you should stay away of QtQuick criticism.

[volomike1]

That's rather vague, don't you think?

[defiancedigital]

No