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.
I'm not trolling. Someone told me, "Hey, you're a C++ coder. You have like no design skills. I've seen your stuff. It needs work." The investor then brought in a UI expert and wowed me. It was then that I realized, "Wow, I don't have good UI skills." I imagine this is probably the case with many C++ coders. Sorry to offend if you're an awesome UI expert AND a C++ coder.
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.
My understanding is that with Qt, you can keep your own Qt source compiled (and not shared) and use the open source license of Qt, but must dynamically link to the runtimes, list the open source license in your application directory, and list a URL where people can download the source of those Qt runtime DLLs that you are linking.
Also, I found the widgets sub-par to modern interfaces you see on the web today. Let me give you a good example. Do you know those "Check All" checkboxes at the top of grids to check all the checkboxes on the left column of a grid? Yeah, to do that with Qt widgets requires subclassing and intercepting paint events. To me, that's a kludge. So then there's QtQuick. When I compared what I could do in QtQuick compared to what I could do with Webkit/jQuery/CSS, I wondered why be hampered by the limitations of QtQuick when I could just get it all in Webkit/jQuery/CSS. So, I opted to build my stuff in Webkit/jQuery/CSS and use the C++/Webkit bridge that adds an object to the DOM that I can interface with jQuery. The other advantage is that I can hire a web designer (cheaper than a C++ coder (who, often have poor interface skills, anyway)) who knows a bit about jQuery/CSS to design the interfaces for me (they appear in the upper left corner of a web page). We make them web server-less -- they load with file:// handles. Then, I still have the option to IFRAME web content as well as use REST-like APIs (JSON or XML) via jQuery to interact with the web server, or let the C++ interact with the web server over REST-like APIs. The other great reason to use Webkit is because it has a vast library of freely explained techniques for great interface widgets.
There was also a mention about charts. I use Chartjs.org inside my Webkit interface.
The only drawback about going with this Webkit technique is that it does increase the size of your project considerably. On Windows, there's no getting around this. However, on the Mac, the way I got around it was to take my Webkit interface and port it to Objective C/C++ (and try to keep most of it in C++ because I find ObjC quite messy and bizarre, and because I can wrap ObjC stuff in C++). I use a Webkit widget on a form, and it uses the native webkit that comes with the Mac. Therefore, the installer download is tremendously smaller. I then ported the Qt/C++ code into ObjC/C++ -- that wasn't easy, but was manageable for any trained C++ coder.
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.