This is high-level, loose assemblage of discussion and links.
Context: you have a cross-platform app written using Qt and PyQt. It is written using QWidgets. You want to switch from QWidgets to QML.
The discussion is not exclusive to PyQt. Much of the discussion also applies to apps writtent in C++, but mentions PyQt also.
This might also have some relevance for apps written purely in QML/Qt Quick.
Why switch to QML from QWidget?
These are possible reasons:
- QML uses native platform style whereas QWidget fails to have native look and feel on some platforms (iOS)
- QML more strongly follows the ModelViewController paradigm
- QML is declarative (more compact and dense)
- a QML GUI is easier to change (to provide multiple or improved GUI’s for the same business model)
To me, the first reason is the most compelling. The last reason is least compelling: you probably won’t be changing the GUI often (but then here we are talking about changing at least the implementation of a GUI.)
(Qt apps are excluded from the Windows Store because Qt did not support Windows8/WinRt but Qt5.4 and QML may remedy that?)
Model View Controller paradigm
Qt documentation: Model – View Options in Qt
Wiki: Model–view–controller
It is quite likely that your existing QWidget apps does not strictly adhere to the MVC paradigm. Thus you will be probably need to refactor your code: separate model code from view code.
A strategy for developing (code changes) to switch to QML from QWidget
Assuming your app using QWidgets already runs and has tests, a good strategy is to keep the QWidget implementation of the View working, while you develop the QML implementation of the View. In other words, use test driven development: make small changes, then test the QWidget implementation AND the QML implementation. The QWidget implementation should always remain fully functional after each change. The QML implementation will also always work, but in a stubbed-out, minimal fashion.
Changing the existing QWidget app will largely entail:
- splitting classes along model/view lines
- converting procedure calls to signals, connections, and properties
Swapping in the QML implementation of the view will be just a small change in the startup code: creating QML instead of QWidgets. (Its a little more complicated than that, you might be making connections in the QML instead of in the main app.)
Embedding QML in a QWidget app
You can implement the main app window (and all other GUI) in QML. But you can also embed QML GUI inside a QWidget app.
Briefly, it entails using QQuickView. But a QQuickView not is-a QWidget. But you can wrap a QQuickView in a QWidget: Qt documentation: Introducing QWidget::createWindowContainer() discusses how to wrap a QQuickView in a QWidget.
Why retain a QWidget shell embedding QML? I suspect there are few reasons to do so. One reason might be just the strategy discussed above; get your feet wet by embedding QML and make the last step converting the main window from QWidget to QML.
My reason was different: my app uses elaborate UI picking of objects from a QGraphicsScene. The QML scene graph doesn’t expose the same API for picking that the QGraphicsScene does.
More on the interface between model and view using QML
Qt documentation:
Where ‘from C++’ more generally means ‘from model objects’ . And the discussion applies to model objects written in PyQt.
The interaction is two-way, bidirectional:
- Control (in MVC) is from the view to the model
- View is from the model to the view
Your interaction may be one direction or both:
- a weather app is just a viewer of the weather
- a styling app is just a controller of a document
Much of the logic in the QML is not business logic, just GUI logic. For example, a button may switch pages and have no effect on the business model. The button ‘controls’ the view, but not the business model.
Not all the interaction need be between the model and the view. For example, if you are embedding QML in a QWidget app, the QWidget app may need to simply activate (show, make visible) a QML view component. In other words, the interactions may be between the part of the view implemented in QWidgets and the part of the view implemented in QML.
PyQt and QML
PyQt fully supports QML. You can use Python and PyQt for your model.
PyQt documentation: Integrating Python and QML
I have shared a hacky Github project where I learn and test PyQt and QML.
For the same reason you use QML for the view, you should consider Python for the model (more expressive in fewer lines of code.)
The QML tradeoff: more portable but less native?
Typically, a cross-platform solution makes certain compromises. Sometimes its discussed using terms such as “least common denominator” or “adaption.”
I can’t fully discuss this here. (And probably the set of compromises that have been made are not fully documented in one place.) But you should consider whether you will be able to live with any such compromises.
For example, I found that a QML Dialog on a desktop (Linux, I haven’t tested OSX) opens in a separate window, not on top of (transient to) the main window. That probably doesn’t meet the HIG’s for desktops. Possibly there is a solution that I haven’t yet found. Or possibly I should look at that as a feature to embrace: I should make my dialogs non-modal and treat them as tear-offs that should not obscure the main window anyway. But its an example of the compromises you might need to make.
There is much more to discuss here. Briefly, Qt Quick Controls does use native widgets where possible, then falls back to QWidget implementations if possible, and then to a pure-QML implementation.
But again, its hard to know in advance without trying it.
Structuring your QML source code
In many examples, you see long QML files. I think that is an artifact of being an example: put everything in one file for ease of reading. You can structure you QML source files into smaller files in more directories, using imports.
Qt documentation: Import Statements | QtQml 5.3
Packaging your app
I don’t foresee any show stoppers here. Just more to learn. If you are already packaging a PyQt app, you probably are already packaging resources using pyrcc. The QML is just another resource to package.
But, I’m not sure how third-party QML plugins get packaged?
A strange architecture: PyQt and QML uses two interpreters
A PyQt app using QML uses two interpreters: the Python interpreter and QML’s Javascript interpreter. (And on Android, there is a third Java interpreter.) There is much discussion about the safety of, and constraints applied by app stores, re interpreters. But this is just a curiousity, there are already shipping apps, using interpreters, in the stores .
A template for QML using models
Qt’s example Weather App is a starting place for reading code: Cross-Platform Applications in iOS and Android Stores with Qt
(I hope to reduce it to a simple template.)
Desktop to Mobile GUI difference: sharing
The main problem that I have found is that for certain apps (document editing or creation apps as opposed to reading or browings apps) the desktop:
- exposes the file system to the user (in the File menu)
- uses drag and drop
whereas mobile platforms use the notion of ‘sharing’ to the file system and other apps
Notably lacking in Qt Quick Control is a ‘share sheet’. A github project QtSharingKit seeks to remedy that, with a QML plugin.
Pragmatically, that means more work for you:
- learning what QML plugins are ( Creating C++ Plugins for QML )
- building another third-party module and packaging it with your code.
More links about QML, Qt Quick, and Quick Controls.
You use these technology pieces:
- QML a language.
- Qt Quick: the standard library of types and functionality for QML
- Qt Quick Controls: canned (pre-built) QUI controls built using QML
- QML Applications
plashless 