[Development] QML and JavaScript extensions

[Alan Alpert]

On Fri, Nov 15, 2013 at 2:00 AM, Kevin Krammer <kevin.krammer at kdab.com> wrote:
> On Thursday, 2013-11-14, 21:20:25, Topi Mäenpää wrote:
>
>> > But that's a long term plan, v4vm isn't even released yet (new in 5.2
>> > remember) and there's still tons of work to do. Until v4vm is ready to
>> > take over from QtScript, which will still be a while, I believe the
>> > recommendation is to keep using QtScript. It's deprecated and "done"
>> > because we've reallocated development priorities, but until we've
>> > finished its replacement it is your best option. Even though it means
>> > using old or no QML, it sounds like the JS support is more important
>> > for you.
>>
>> I considered the options carefully before switching to Qt5. I talked to
>> Digia engineers and they told me the same you are telling now: QtScript
>> will be deprecated and definitely not accessible from QML. Therefore, it
>> was completely out of question. I don't think building anything serious
>> on a deprecated API is a good idea anyway.
>
> That could have been a miscommunication. What they probably meant was that the
> standard QtQuick module would not have a QML type for QScriptEngine.
>
> QScriptEngine can certainly be accessed from QML. Sure evaluate is currently
> neither a slot nor a Q_INVOKABLE, but that would easily added and/or worked
> around by a simple subclass or wrapper.
>
> Remember that any default constructible QObject class can be instantiated by
> QML, its slots, signals, properties and Q_INVOKABLEs becoming available.
> QML is just the "glue" between object instances, it doesn't care what those
> objects do internally.

I think he's talking about JS integration into QML. It's the difference between
MyObject {
    prop: Math.min(alpha.foo, beta.bar);
}
and
MyObject {
    prop: "Math.min(alpha.foo, beta.bar);"
}

Sure, you can do the latter. Maybe even query the QQmlContext for
evaluating unrecognized symbols such as alpha.foo. Then you start to
reimplement binding logic and you start asking yourself "why am I
doing this again?".

So you can use QScriptEngine from QML in 5.2 just like you could use
QScriptEngine in Qt 4.6 (before QML). But you're missing out on a lot
of progress, and you aren't getting the value out of QML anymore,
which is why I'm asking whether you need QML in your application (yes,
every application would benefit from QML but I'm not going to claim
every application *needs* it ;) ).

>> Qt is heading to a JavaScript-based future. Widgets are deprecated and
>> replaced by QML. In this situation, a good extension interface to the
>> JavaScript engine that runs QML is a really important feature.
>
> I have to disagree with a couple of items here.
>
> Qt has already had JavaScript based scripting support for ages, so it is not
> heading into using it.  As for JS in QML, any sensibly designed application
> will avoid doing business logic process in the UI. That was already not a good
> idea when using C++, no need to continue bad practise when the new UI
> technology hands you a nice way to correct that.
>
> I also wouldn't consider widgets to be deprecated, at least not yet. And
> nicely use QML with widgets as the UI elements, it is not replacing one with
> the other either (though you probably meant QtQuick when you wrote QML there).

Yeah, QML doesn't deprecate widgets - it deprecates .ui files because
now you can construct your widget UIs in QML :D . Long ago we
discussed deprecating widgets because Nokia wanted to reallocate those
development resources to QML/QtQuick, but thankfully open governance
swooped in and saved the day.

Assuming you meant QtQuick there: Qt Quick-based development, even
Components IMHO, is expected to take over for future *style* of UIs
(I'd say mobile, but then take a look at Windows 8...). I expect
"Classic" style UIs will continue to use widgets until Qt 6 at the
earliest.

--
Alan Alpert