First look: Qt 5 makes JavaScript a first-class citizen for app development
arstechnica.com
arstechnica.com
As for the advantages of QML over HTML and JavaScript - well, a sane layout model for one, proper support for modules/packages, ...
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.
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.)
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!
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...
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.
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.
seems like MS and Nokia are both trying to attract JS developers.
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.
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.