You mean QML? It's weird to see all of the C++ API reduced to a chapter. I've used Qt for years and QWidgets from C++ is all I've used.
> Qt Quick is the umbrella term for the user interface technology used in Qt 5.
It is not "the" user interface technology in Qt, but one of them. This is a very confusing way to start a book that is supposed to be an introduction to Qt.
Basically all the classic QtWidgets and the underneath desktop services.
I'm sure it's a nice book, though.
My personal opinion of QML is also contradictional: QML on the desktop to me just feels like a glorified Electron, resizing windows is choppy, controls feel slightly "off", the "single page" approach just feels like it misses the platform's defining features (dialogs and multiple windows). Best example is KDE Discover. But I'd like to be proven wrong, I'd love to hear of QML desktop software that is genuinely high quality, but I haven't heard of any.
For multiple pages, you can create multiple Windows / ApplicationWindows for one app. It definitely could have more support though - as for now you have to control these via C++ Qt code.
I gather QML was a push for mobile (which is in line with your criticisms) where QtWidgets wouldn't work at all. It happens to coincide with Electron bringing the mobile UI and web platform back to the desktop.
Funny thing, a lot of the 3d apps themselves (Nuke, Maya, Houdini) have very custom UIs and have all ported to Qt. But this transitioned happened just before Qt5 so I'm pretty sure it's all heavily modified QtWidgets where QML might have been simpler to implement. However, any performance issues or drawing glitches might have been a dealbreaker. That's so important that these companies actually grouped together and forked Qt 5.6.1[1] with their own backported bug fixes and critical changes. Thankfully they've been working with The Qt Company to integrate them into mainline.
[1] https://github.com/autodesk-forks/qtbase/tree/adsk-contrib/v...
Er, they actually worked fine on Maemo/Meego. I think even Android was supported at some point. But it has never been “cool”, and Nokia were desperate for getting cool.
QML was an attempt at doing what Electron has done, but starting from the other end (i.e. desktop -> web, rather than the other way around). It was aimed squarely at “cool web people” trying to build desktop and mobile apps. I believe it was also supposed to be married with some integrated cloud service (where rendering a QML-based interface in-browser was obviously going to be much easier than reimplementing QtWidgets), but I had no interest in that sort of thing at the time, and I don’t know the current situation.
Maemo was basically a full Linux though. It was closer to desktop squeezed into a mobile screen than a mobile platform, so lots of things could be compiled and "just work".
Edit: to clarify, I mean the original Qt C++ toolkit, not the Python bindings (pyqt/pyside); the bindings only ever worked on Maemo, if i remember correctly.
First they had to create PIPS, a POSIX environment for Symbian, because Symbian wasn't POSIX and the native language was a C++ dialect known as just Symbian C++.
Secondly, the Qt based apps weren't pure Qt, you needed to have a couple of #ifdefs sprinkled around, calling Symbian APIs directly, even for a plain hello world.
My only real problem with QML is that things can get really hairy really fast. QML does a great job of abstracting over it, but the complexity is all still there underneath. When something goes wrong, you end up debugging a tangeled mess of implicit behaviours, many of which were probably unintentional and unnoticed by anyone (including the original author that created them).
Long before then and before Nokia even, back when smartphones were called PDA's, the iphone wasn't released and when maemo was GTK based, there was a QtWidgets based environment called qtopia (https://en.wikipedia.org/wiki/Qt_Extended).
You can get the latest update on their Meeting C++ 2018 session.
"Recent developments and future outlook of Qt"
Were you at SIGGRAPH? One of these days I’m going to make it to the conference and attend a meeting on the Platform. I was a little disappointed that 3.6 got offset to a tech preview with 2020 as the goal, but it’ll be worth it if we can get everyone using mainline Qt 5.12 AND official 5.12 PySide (Qt for Python...).
The future is bright for the VFX Platform! Just not with QML, Widgets are here to stay for these kinds of apps.
Python3 has been a topic brought up for many years and pushed off for other things. I'm kind of surprised how much progress they've made in moving these companies forward and keeping them roughly in step.
My only concern right now is Autodesk potentially dragging their feet on this, which I really hope they don’t do. But they’ve also got a lot of other things on their plate.
A bit grumpy that their M2019 release is still using Qt 5.6.1 even with their several month delay that went into 2019, but maybe they’ll do something radical and upgrade it through. I remember Wayne and others being happy about the push to GCC 6.3 and finally being able to use C++14.
Um, not really. The inbuilt Universal style looks pretty good by default.
Does Electron handle those scenarios well?