3 ms·

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 maintena

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.

sho_hn 15y ago
> 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.)
- hartror 15y ago
  > 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!

sho_hn 15y ago

> 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.)

hartror 15y ago
> 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!