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

[André Pönitz]

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.

Andre'

I am speaking for myself only