On Fri, Feb 1, 2013 at 4:12 PM, Bob Hood <bho...@comcast.net> wrote: > On 2/1/2013 4:56 PM, André Pönitz wrote: >> On Fri, Feb 01, 2013 at 08:06:03AM +0000, Mark Summerfield wrote: >>> 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. >> [On a side note: This paragraph seems to be based on certain >> assumptions, like that "dropping down to C++" comes at less cost then >> the gain through "rapid prototyping" is. I would be interested in >> learning about any numbers you might have from real projects indicating >> that this is true in practice.] >> >>> 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. >> There is no uniform entity "Qt devs", pretty much as there is no uniform >> entity "Qt users". So I wager a guess and say nobody knows where we'll >> end up in a few years time. >> >> QML covers some use cases that have not been handled by Qt previously, >> most notably the "mobile phone/touch toy app/three days from idea >> to app store" case where "bling" and animations at 60 fps matter. >> >> On the other side, it does not handle much more than that, i.e. essentially >> ignores all the existing Qt use cases and investments in the engineering/ >> number crunching/data visualization space where runtime performance >> and scalability matters. >> >> Both worlds currently barely overlap, and while there is some motion to >> bridge the divide it's hard to imagine a reconciliation in the next few >> years. So the options are more or less that either side A is forcefully >> abandoned, or side B is forcefully abandoned, or that there will be a >> more or less peaceful coexistence between the two. Given the open nature >> of the project, anything "forceful" would be difficult to achieve so my >> second prediction is that we'll see both worlds alive for "eternity". >> Whether there will be a dominant side, and if so which, is up to the >> project contributors and users to influence. > > > Right now, the "dominant side" seems clearly to be QML. That does not bode > well for a high-performance, desktop-based C++ application like mine, and > makes it increasingly difficult for me to evangelize and promote Qt within the > project. This direction is apparent to others on my project, and makes them > (understandably) concerned about full adoption of the framework instead of > other, admittedly less-sophisticated alternative frameworks that continue to > have desktop C++ as their primary focus (so far, at any rate).
There is no "dominant side". C++ and QML are both viable options for writing your UI with Qt (actually, right now QML is not a viable option for the average desktop UI but it's getting close). It's not even two entirely separate worlds, QML depends on C++ development and is primarily focused on the case where they work together. As an open-governance project some areas may seem more interesting and thus draw more attention or contributions. If there's any specific changes you feel should be made to keep the desktop C++ API competitive, you are welcome to contribute them. Maybe there's some confusion about the separate worlds of Widgets (with its C++ only API) and QtQuick (with its QML only API). In that case, they're also targeting separate use-cases so there's little need for convergence. Widgets will continue to work for the classic desktop-based applications, and QtQuick still has a lot of work to be just as good for mobile as widgets already are for desktop. -- Alan Alpert _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
