Alan has been developing Qt since he was a Trolltech employee, and was a member of the original Brisbane team which developed QML. His mission, continuing in Blackberry, is to support the creation of modern and pixel-perfect mobile UIs using Qt and QML. He is currently the QtQuick maintainer and spends most of his time developing further QML and QtQuick features.
For a standard QtQuick application, you’ll have C++ application logic and a QML UI. What if we challenge that approach? This presentation will contain examples and use cases where you might overturn that convention, and more importantly the discussion of why it might make sense for that specific use case.
Three usecases will be considered. Where you have the UI in C++, using QML as a data or configuration storage language (JSON++). With a C++ UI, using QML for application logic (JS gluecode a la node.js). Or with any UI, QML and QtQuick can be used as a scripting language which will eventually exceed the capabilities of QtScript in many ways.
The straight up inversion, C++ UI and QML application logic, may sound silly. This is the point in the presentation where you can laugh and enjoy yourself. But there are situations where it might make sense: The QML API for widgets is not here yet, many applications are porting piecemeal, and some applications might be 100% custom openGL rendering - or even CLI!
When you have your UI in C++, you can still consider using QML as a data language or configuration language, like QBS does. Sometimes JSON just isn’t expressive enough, because you want bindings, or too expressive, when you want locked down data types with some degree of type safety built in. QML adds additional structure and some program flow that can richen your data format.
What about application logic? JS glue code is huge right now (such as node.js). You can easily insert some JS glue code to your existing signals and slots using QML. You can even use the network transparency of QML for instant updates to a frequently changing logic section. For more rigorous control, the upcoming Declarative State Machine module in 5.4 provides an easier to write interface for the Qt State Machine Framework.
A third possibility, QML as a scripting language. QtScript was deprecated by QtQml, and we’re still catching up in some ways, but in others we’ve made significant advances. You can still do a lot of scripting in a constrained QML engine, with greater ease and the ability to script defined chunks of UI as well. Here we’ll even get speculative, and discuss some of the theoretical features of the language designed to support embedding QML as a scripting language. It’s a glimpse into the future, when we really will do everything QtScript did and more.
All up, QtQuick and C++ make an excellent team. But there’s more to it than the stock standard UI/logic split, even if that’s what works best. There are many niche use-cases where you might want to consider using QML for something other than the application’s primary UI framework.