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

[Alan Alpert]

On Fri, Feb 1, 2013 at 4:12 PM, Bob Hood <bhood2 at 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.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).

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