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

[Bob Hood]

On 2/1/2013 1:37 AM, Bo Thorsen wrote:
> Den 01-02-2013 09:06, Mark Summerfield skrev:
>> 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.
>>
>> 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.
> You probably won't get an answer to this, because I doubt anyone really 
> know where this is heading. It's a HUGE task to expose the entire Qt API 
> to QML, and it might not make sense or even map 1:1 to the QML code 
> model, so no one will commit to this.
>
> I take a fairly laid back approach to this. If it happens, I might use 
> this option. If not, I'll just do as I do right now, which is to always 
> have C++ layers as well.
>
> Personally, I think this is one of the cases where it's better to let 
> the project evolve than try to make a decision on what should be the 
> direction.


Unfortunately, that seems like a sloppy approach for a something that may be
entrenched in hundreds of shipping applications.  I've never seen Qt handled
like a college research project, and I'd be disappointed to see it take that
direction now.  Without a firm commitment to a direction, or a road map that
outlines the future of the framework upon which dependency decisions can be
based, it becomes much harder to champion Qt on a project.  Yes, it's open
source, and you get what you pay for.  However, unlike some other OS projects
upon which we have become dependent, I've never gotten the feeling that Qt was
in the hands of people for whom the project was something they did only on the
weekend.  Just letting "the project evolve" would unavoidably erode this
feeling of confidence in adopting Qt.

My $0.02.