[Interest] Direction of Qt [Was: Re: QML Runtime]

[Bob Hood]

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