3 ms·

Ive been using QtQuick for a while now and the last two weeks i've battled with 5.7RC. So, time to dl the proper release and see if it works any better. My con

Ive been using QtQuick for a while now and the last two weeks i've battled with 5.7RC. So, time to dl the proper release and see if it works any better. My conclusions are that it's fantastic for desktop apps, but I'm having a lot less success with mobile, specifically Android. Originally, my plan was to reserve QT for desktop and write the mobile versions separately, whilst sharing the same C++ backend. However, i got tempted to try cross compiling my desktop version for Android. After a massive battle, it works - a bit. But there's enough that doesn't work that prevents me from making a release just yet (cut & paste is missing!). Looks like I'll have to fill in the blanks myself. Then Android is always a pig. I'm chewing over whether to recompile QT from source and start hacking it about for Android. This is what Ive had to do with pretty much all the cross platform systems. Android support is always poor and buggy. On LGPL, I'm fine with it. If you want my QML source code, sure. But for now, I'll keep the backend DLL/.so closed (although I'd like to open that too, when ready). If you want to be able to change the front end and rebuild, I'm ok with that too. in fact, I'll happily document the backend interface for you. Can we have more Controls.2 QML examples please (most are recycled v1 examples). QtQuick lacks in the tutorial department, although the online docs are good, once you know what you're looking for. qmake is great, but qtcreator sucks, sorry. Qt widgets is obsolete, QtQuick is the way, once you get over QML.

volomike1 10y ago
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.
- defiancedigital 10y ago
  If you have never taste the limit of Webkit/HTML/CSS/jQuery for client side application, you should stay away of QtQuick criticism.
  - volomike1 10y ago
    That's rather vague, don't you think?
    - defiancedigital 10y ago
      No
- steaminghacker 10y ago
  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 10y ago
    > 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 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 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 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 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_platforms 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.

volomike1 10y ago

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.

defiancedigital 10y ago
If you have never taste the limit of Webkit/HTML/CSS/jQuery for client side application, you should stay away of QtQuick criticism.
- volomike1 10y ago
  That's rather vague, don't you think?
  - defiancedigital 10y ago
    No
steaminghacker 10y ago
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 10y ago
  > 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 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 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 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 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_platforms 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.