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

    I completely disagree that QML is only for prototyping or the UI since I am developing entire applications in QML/JavaScript and don't intend to use C++ unless it's absolutely necessary. It seems like some people downplay or don't completely realize the power of QML; it is a more productive and expressive way of developing applications than with C++. If you look at node.js and all of the current and rapidly increasing number of modules available, it should be readily apparent that JavaScript, especially coupled with QML as in Qt, is a very powerful approach to software development. End users don't care what languages, product or tools have been used to create an application. They are just interested in what they see, the features offered, their experience with the application, etc.

    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.

    I'd personally also like to see more capabilities in Qt Creator and especially Qt Quick Designer, such as adding more QML types, and enhancing Qt's design capabilities. Systems like V-Play enable the users to develop applications in QML/JavaScript without any C++. Box2D, a level editor, a particle editor, in-app purchases, ads, etc are integrated with and supported by V-Play, along with other features. This is all done with just a small cadre of people. [By the way, I am not affiliated with V-Play and no financial interest in the company.]

    Just think what could be done if the entire Qt community started proactively planning for the future and then brought their ideas to fruition.

    Thanks.

    Steve


  • Moderators

    [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 ?



  • cincirin,

    I'm not suggesting that computationally intensive algorithms be written in QML, especially if there is no or minimal UI; that's your choice. I am suggesting that C++ is not always the best or only choice for the "back end" and that there are times when QML may be a better alternative. Algorithms have been written in C++, JavaScript, QML and just about any language you can imagine and are often just part of a complete system.

    If QML has a good optimizing compiler, then there may not be a tremendous performance degradation using QML/JavaScript as compared to C++. This obviously partly depends upon the algorithm and chosen implementation. However, I have not seen any performance figures to compare the two approaches, especially as this would be on a case by case basis.

    I do wish you well in your development.

    Steve



  • Tomasz,

    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.

    Steve



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



  • stereomatching,

    Perhaps I'm just an optimist but I can see the power inherent in QML/JavaScript, especially when I see what's happening with node.js. Emscripten has been used to convert C++ and other code to JavaScript, possibly requiring some "tweaking" of the code produced. As an example, OpenCV.js has been created using Emscripten but more work is needed and ongoing. In addition, there are node.js bindings for OpenCV but an installed OpenCV is required.

    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.

    Steve



  • Andre,

    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.

    Thanks.

    Steve



  • [quote author="SteveG" date="1391661159"]s
    there are node.js bindings for OpenCV but an installed OpenCV is required.
    [/quote]

    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.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.