4 ms·

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 proff

by sho_hn 15y ago

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

hartror 15y ago
Exactly. 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!
- jlarocco 15y ago
  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...
  - mullr 15y ago
    You can expose any QObject to a QWebView, it shows up as a property of the window object. It's remarkably easy.
  - daliusd 15y ago
    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.
  - hartror 15y ago
    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.
- slug 15y ago
  How would you compare using QML to a Qt wrapper for a interpreted language, say python-qt / pyside ?
danieldk 15y ago
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.)

by sho_hn 15y ago

hartror 15y ago

Exactly. 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!

jlarocco 15y ago
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...
- mullr 15y ago
  You can expose any QObject to a QWebView, it shows up as a property of the window object. It's remarkably easy.
- daliusd 15y ago
  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.
- hartror 15y ago
  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.
slug 15y ago
How would you compare using QML to a Qt wrapper for a interpreted language, say python-qt / pyside ?

danieldk 15y ago

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