[CLOSED] The Future of Qt and QML?
A "May 2013 post":http://qt-project.org/forums/viewthread/27868/ stated
bq. Pure QML applications are only for prototyping, or for the UI design (to be later combined with a C++ backend). So QML frontend + QML backend is for prototyping and UI pre-release. QML frontend and C++ backend is for the final, best performing release.
A "January 2014 post":http://qt-project.org/forums/viewthread/37605/ stated
bq. Nothing is happening on Canvas right now because there isn’t much use of it, or much room to extend. It’s just following an HTML5 API specification, and is specifically for convenient, imperative rendering. The role of imperative rendering in a QML scene is not established yet, so we’re waiting to see if it’s used much other than just for graphing.
Certainly much more than graphics can be developed and QML's potential is virtually limitless. Part of Qt's attractiveness and expressiveness should be the ability to use more of the 1,000+ C++ classes directly within the QML framework. There's no visibility into any future roadmaps so people can't be certain what the evolution and enhancements will be for QML or even Qt. I realize that Qt is an open source product, although Lars Knoll and others at Digia have a huge stake in the product, but there should be more planning and stategizing made visible to the general public, if any's even being done.
Just think what could be done if the entire Qt community started proactively planning for the future and then brought their ideas to fruition.
[quote author="SteveG" date="1391543539"]Part of Qt's attractiveness and expressiveness should be the ability to use more of the 1,000 C++ classes directly within the QML framework.[/quote]
Tha is unlikely to happen (it has been proposed back in the days of Qt 5.0 alpha, I think). Adding Q_INVOKABLE to all Qt classes would put too much overhead. Plus, a lot of QtCore classes are not QObjects to improve performance, so it's impossible to add it for them.
bq. don’t intend to use C++ unless it’s absolutely necessary
It's your choice. If you develop application with fluid Ui maybe it's the right choice. In contrast we develop applications where algorithms and math calculations and so on are heavy used.
bq. it is a more productive and expressive way of developing applications than with C++
We don't need fluid Ui at all. Why do you think we can develop all algorithms in pure QML ?
I do wish you well in your development.
I wasn't trying to imply that all of the C++ classes be useable from QML. However, as there are three times the number of C++ classes as there are QML types, I thought that more of them can probably have QML "counterparts" to enrichen the QML environment and provide more capabilities.
As time progresses, I'm sure you'll see more and more QML components becoming available. Rome wasn't build in a day, and neither was and is QML/QtQuick
bq. especially if there is no or minimal UI
Steve, contrary we develop applications where Ui is quite intensive but not necessary fluid. For example we have developed some Photoshop like apps, AutoCad or Matlab like. For the time being I don't see how can we use QML here or at least I don't see any advantage over traditionally widgets and their C++ implementation.
p.s. I would go further and even QtCreator heavily use C++/widgets
bq. I do wish you well in your development.
The same to you :-)
I like qml and hope it could have more modules in the future, but I don't think it is possible to develop all types of apps by qml + js, like image processing, computer vision. I can't find any free, open source, high quality libraries like opencv2 or Thrust in the realm of js(Besides, I find out that it is always easier to write fast codes by c++).
Besides, the desktop part of qml is not mature yet even QtQuick control is out
1 : The component is not as rich as QWidget
2 : Describe the UI by qml is pretty easy and elegant, but with the help of QtDesigner, we don't even need to codes.
C++ is ubiquitous, as is C, and may be required for computationally intensive or other tasks. However, it is my hope that Qt in general and QML in specific will evolve to become one of the premier tools to develop software applications, especially mobile ones.
I agree that Rome wasn't built in a day but Rome had architects and planners. Qt has maintainers but I have no idea who performs the other functions. I've inquired about roadmaps in some of my previous posts but still have no visibility into what's being done. If you do, please share this info.
[quote author="SteveG" date="1391661159"]s
there are node.js bindings for OpenCV but an installed OpenCV is required.
1 : For math heavy apps , you always need to develop the algorithms which do not implement by the libraries yet(ex : manipulate pixels efficiently), or fine tune the performance(GPGPU, openMP, vectorization etc)
2 : opencv2 work very well with c++, there are no reason for me to use some js binding or Emscripten.
3 : Nothing is perfect, this is why we need different programming languages.One man's meat is another man's poison.
4 : Qt is an open source project, if you need more module go into QML, you could contribute it by yourself.