[Interest] Direction of Qt [Was: Re: QML Runtime]
list at qtrac.plus.com
Fri Feb 1 09:06:03 CET 2013
On Wed, 30 Jan 2013 12:50:53 +0000
Rutledge Shawn <Shawn.Rutledge at digia.com> wrote:
> >>> - 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.
> > 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.
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.
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Programming in Python 3" - ISBN 0321680561
More information about the Interest