I wouldn't really call this a "move away from C++", necessarily. In practice, you end up writing your backend in C++ and your frontend in QML; the backend proffers data models the QML then pours into a user interface.
As for the advantages of QML over HTML and JavaScript - well, a sane layout model for one, proper support for modules/packages, ...
I wouldn't really call this a "move away from C++", necessarily.
The Qt developers have said that the traditional widgets have practically been put in maintenance mode, and that all development will be in Qt Quick's dynamic interfaces (QML is part of Quick).
The problem, however, is that Qt has no foothold in mobile devices. That window of opportunity has closed when Nokia switched to Windows Phone 7 and ditch Maemo/Meego. And on the desktop... if I want web-ish interfaces, why wouldn't I just target the browser?
There is a huge community of users that uses Qt to just write (and maintain) desktop applications. Qt Quick sucks for that. Besides that, you cannot expect huge existing applications to switch to Quick. For those users, the future of Qt seems bleak: it's not in the hands of a company that caters to that audience (Trolltech's primary source of income was Qt, Nokia's is cell phones) and development pace is glacial.
> The problem, however, is that Qt has no foothold in mobile devices.
It's more or less an open secret that Nokia has a Linux/Qt-based S40 replacement powered by Qt in the works, from all the rumors floating around (keyword "Meltemi"). I'll not speculate on its success potential; Nokia has disappointed me in the past. As a Qt user, I do hope it will do well.
> There is a huge community of users that uses Qt to just write (and maintain) desktop applications.
Believe me, I know. I write and maintain some of them. I'm a KDE developer.
> Qt Quick sucks for that.
Depends. We're getting some rather good mileage out of QML in our desktop shell, actually, and for some _componments_ of regular applications it'll do very nicely in short order as well.
I agree that Quick isn't there yet in terms of being a full QWidget replacement, though. Right now there's somewhat of a gulf where some things that are hard with QWidget are wonderfully easy with QML, but once you leave QML's prime areas of competence and need to customize, it gets a lot harder than customizing QWidget tends to be.
The Ars article actually cites a really good example that I've hit upon myself, as one of the apps I maintain is a heavy user of QTextDocument technology. Because the QML Text items do not allow low-level access to the QTextDocument they're based on, if you want to do advanced QTextDocument stuff in QML, you need to go quite low-level and write your own QML items in C++. It's doable, but QTextBrowser & Co allow more direct access under the hood and don't invite that overhead.
However, QWidget is staying put in Qt 5, and QML is still relatively young. There's ample time for a transition to occur. Let's hope it'll work out well.
> For those users, the future of Qt seems bleak: it's not in the hands of a company that caters to that audience (Trolltech's primary source of income was Qt, Nokia's is cell phones) and development pace is glacial.
While I'm onboard with a healthy dose of skepticism and staying aware of possible trouble, my own outlook is really not that bleak. Under Nokia, Qt has become a pretty decent open source project with working contribution paths - something it never was under Trolltech. KDE has contributed tens of thousands of lines of code to Qt thanks to that, and we remain a heavy user of QWidget at the momemt. I'm not saying we wouldn't be even better off if Nokia were more interested in the desktop, but I feel we have a shot at making our own future.
(Of course, KDE is also looking at mobile; see our tablet user interface Plasma Active. It won't surprise you to learn that it's quite heavily based on QML.)
> Because the QML Text items do not allow low-level access to the QTextDocument they're based on.
This has been a bit of a pain for me, it seems to be common with the QML items that you cannot get at the underlying object. I had write my own WebView item as I couldn't give each item its own cookie jar. It seems a bit of a oversight, ideally one could inherit all items in C++ to extend their functionality.
And lets not even talk about WebView blocking the main thread. Still, it is a very useful project that has allowed me to produce some great work!
I have been writing a QML application the past couple of months. I have written a lot of real time C++ then tied it together with QML. It has given me a flexibility in how the components interact, being able to change functionality with little effort has allowed me to have low turn around when the design has evolved.
The application is such (embedded hardware with video playing) that not many solutions have both the agility and performance that QML offers me.
Gee sounds almost like marketing copy, but it is true!
Could the same thing be done using plain HTML inside a QWebView?
Honestly, I should probably look into it a little more before asking questions like these, but so far I've just got the impression it's not worth the time...
No, the same thing can't be done using plain HTML (+ Javascript and CSS). You can get result that visually and functionally looks the same but it will be very hard to get desired result (it is not worth the time), e.g. have you ever tried to get window height in HTML and do something with that? Actually I would love if I could use QML instead of HTML in browser in some cases. HTML and QML has quite different purpose: HTML is for documents that can be styled using CSS, while QML is for UI. Web apps could benefit from QML a lot if we could use it in browser. However I guess there is no interest for that most probably, because with FireFox you can write web apps using XUL for at least 6 years already (if not more) - the only problem is that apps will not be cross-browser.
Exposing C++ objects to QML is blindingly fast and what's more it is well documented front and centre. The documentation is especially important as I am a contractor and I want to leave my client with a maintainable system.
As someone that develops in Qt for lower-end embedded systems, it's even worse. QML was a dog when you ran on anything slower than ~500 MHz and had all kinds of stuff bound to the frontend, mostly because of the script core. Now that the script core is going to need V8? That's gonna tank my CPU even more, if I can even get it cross-compiled for my target.
I'm not even sure how this dovetails with QWS being deprecated for Lighthouse. I've given up trying to understand Qt's roadmap post-Nokia and how it relates to my designs. I might be stuck with 4.8 forever.
Keep in mind that QML in 4.8 is doing software rasterization while QML in Qt 5 is running via OpenGL ES on the GPU. And yes, that does matter, since making it easy to accelerate is the entire point of going declarative.
But the Javascript interpretation and C++ binding is still taking place on the core CPU. Some of the biggest lag I've seen is when object properties bound to C++ need updating.
I'm sure GLES rendering will be great for mobile systems. Will rasterization under Lighthouse for old QWS deployments get the same attention and optimization? I don't see any interest from the developers in that area. Haven't seen it for years now.
Cross-platform mobile development isn't still mature enough, and for Nokia it would be a winning move to create a great tool that allowed developers to easily create apps for iOS, Android, and then whatever OS will run on Nokia phones.
I hope they will at least look at XUL to try and understand what is good and what is suboptimal in that space.
This sounds like a great thing (less C++ means wider availability of potential developers), but I will be really sad for my industry if QML ends up running into the same landmines that XUL has already uncovered.
Not that I know of. Gnome Shell makes heavy use of JavaScript, but in a way unrelated to GTK+ itself. JavaScript bindings are of course also nothing new in the Qt world; KDE has had KJSEmbed for many years to write KDE/Qt apps in JavaScript, and Qt itself offers QtScript to generate ECMAScript bindings to Qt APIs for years as well.
Qt 5 goes quite bit beyond simply allowing you to access traditional C++-style APIs from JavaScript, however, it essentially implements an all-new UI toolkit based around a declarative language dubbed QML that is actually JavaScript and lets you jot down UIs and their behaviors in a sort of JSON-plus-logic fashion.
