For the foreseeable future, the official guidance will still be to use QML for your UI and C++ for your logic. There's the direction you can use for your planning, and it will certainly continue to be supported. That is the primary usecase of QML, after all.
In the long term, it is being *deliberately* evolved so that QML can support more and more usecases over time. This is why key strategic areas, like the QML runtime and the QtQuick.Window module, are being worked on to increase the amount of applications which can go QML only. As we get closer to that far away goal, we can see just how feasible it really is. So while it's too far away to "commit" to, there is deliberate progress in the direction of making more pure QML apps possible. Given how young QML is, it will still be a quite a while before large applications don't need any C++. But when the runtime and the Window module are more complete, small applications may become possible to do with just QML (primarily targeting apps that are 99% UI). -- Alan Alpert On Fri, Feb 1, 2013 at 10:15 AM, Bob Hood <bho...@comcast.net> wrote: > On 2/1/2013 1:37 AM, Bo Thorsen wrote: >> Den 01-02-2013 09:06, Mark Summerfield skrev: >>> Hi Shawn, >>> >>> On Wed, 30 Jan 2013 12:50:53 +0000 >>> Rutledge Shawn <shawn.rutle...@digia.com> wrote: >>> [snip] >>>>>>> - Would this mean that QML would be able to access all or most of >>>>>>> the Qt C++ APIs (e.g., QFile, etc.)? >>>>>> No, adding new QtQuick APIs is still more work that needs to be done. >>>>> That's a decision I've seen debated a few times here. On one hand, QML >>>>> feels like a limited tool if you don't have access to the full Qt API >>>>> or at least a much larger subset of it. OTOH, ATM all non-trivial QML >>>>> apps need a C++ side anyway, so why not let people code the C++ >>>>> instead of trying to wrap everything. >>>>> >>>>> The javascript side also has a lot of limitations. Especially because >>>>> there is no available framework to do real work. JS is pretty much >>>>> restricted to manipulate the QML objects. >>>>> >>>>> As the situation is right now, I don't see the point in making it >>>>> possible to run a QML only app. The environment is too weak for this >>>>> to make sense. Sure, there are probably a few apps you can do. But the >>>>> overwhelming amount of QML apps will need C++ coding as well. >>>> Yeah but it should get better over time. >>> ISTM that many people will want to create pure QML/JavaScript apps. Some >>> for rapid prototyping; some because their developer costs are more >>> important than runtime efficiency; and some---perhaps most---because >>> they want rapid development & are willing to resolve any efficiency >>> problems by dropping down to C++ when necessary. >>> >>> Is this where Qt is headed? Or will the Qt devs "hold the line" and >>> insist on the need for C++? FWIW I don't have any axe to grind either >>> way, I just want to know where things are going. >> You probably won't get an answer to this, because I doubt anyone really >> know where this is heading. It's a HUGE task to expose the entire Qt API >> to QML, and it might not make sense or even map 1:1 to the QML code >> model, so no one will commit to this. >> >> I take a fairly laid back approach to this. If it happens, I might use >> this option. If not, I'll just do as I do right now, which is to always >> have C++ layers as well. >> >> Personally, I think this is one of the cases where it's better to let >> the project evolve than try to make a decision on what should be the >> direction. > > > Unfortunately, that seems like a sloppy approach for a something that may be > entrenched in hundreds of shipping applications. I've never seen Qt handled > like a college research project, and I'd be disappointed to see it take that > direction now. Without a firm commitment to a direction, or a road map that > outlines the future of the framework upon which dependency decisions can be > based, it becomes much harder to champion Qt on a project. Yes, it's open > source, and you get what you pay for. However, unlike some other OS projects > upon which we have become dependent, I've never gotten the feeling that Qt was > in the hands of people for whom the project was something they did only on the > weekend. Just letting "the project evolve" would unavoidably erode this > feeling of confidence in adopting Qt. > > My $0.02. > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
