[Development] QML and JavaScript extensions

[Kevin Krammer]

On Friday, 2013-11-15, 21:51:37, Topi Mäenpää wrote:
> > I think the existence of JavaScript context in QML should be considered a
> > feature of QML, not of Qt or the application itself.
> 
> Sure, as far as the Qt application is not a QML application. If you run
> the app with qmlscene, the "Qt application" is a pure QML application.

Even when run through a launcher app, the engine will evalute imports and load 
respective QML plugins.
It doesn't matter whether the script engine type is part of QtQuick or, lets 
say, a QtScript import.

What I tried to convey above was that it doesn't matter what language QML uses 
for its UI purposes, an application can add scriptability with any language it 
wants, just like in the QtWidget case.

> > There is a module specifically created for the purpose of general
> > scripting
> > using JavaScript and that is QtScript.
> > 
> > As you wrote yourself, it provides more or less everything you want it to
> > do. In pre-QML times you've had to create a C++ application, probably
> > using QtWidgets if you had UI, and explicitly create, initialize and run
> > your script engine instance.
> 
> I can call even Brainfuck code from my QML apps. There is always a way
> to write wrappers and glue and all that stuff, but it is not going to be
> pretty, efficient, maintainable, or otherwise worth it.

Sure, no argument there. I was just pointing out that the facilities for 
JavaScript do already exist. The module is called QtScript.

I was under the impression that you already had a working solution for your 
specific needs based on QtScript, just with QWidget as the UI component set.

So I pointed out that this would also be applicable with QtQuick. The UI 
elements are still QObjects, they still have properties, signals and I guess 
even slots. They are just drawing differently.

> > I see no reason to do anything different just because of a switch in UI
> > technology.
> > You can still create, initialize and run your script engine instance. You
> > could even make it or a customized wrapper instantiable through QML.
> 
> The switch in the UI technology is exactly the reason why I'm bringing
> this up. I did use QScriptEngine in widget-based applications, but even
> in Qt4, using the same JS extensions in QML apps was a pain. It could
> have been made easy by revealing the QScriptEngine that was used to run
> QML code, but that was never done.

So you have an application scripting solution, using JavaScript. Despite the 
UI not being scriptable itself.
You would still have that if QML used Lua.
So you also still have that if QML uses JavaScript.

I can understand that you'd like to have the same script engine evaluate both 
types of script, but since the decision was to make an optimized version for 
QML, you can either try to shoehorn your code into that limited engine or use 
what you already have.

> > If so, I would imagine that this status could be changed to actively
> > mainained again.
> > 
> > Qt development is a combined effort of multiple parties.
> > If one or more parties have interest in continued development of a
> > scripting module and provide the resources to do it, then I am sure that
> > would change the official status of said module.
> 
> Changing the status doesn't make a difference. QML is based on
> JavaScript, and the object hierarchy already indicates there is a plan
> to provide some sort of a support for generic JavaScript extensions
> (QQmlEngine derives from QJSEngine). I raised the issue here to make
> sure it will get the consideration it deserves when development
> priorities are decided.

I think that indication was the original plan. Before several platform vendors 
decided that they and only they can be trusted to write a secure enough 
JavaScript JIT.

Obviously even if QJSEngine were a full QScriptEngine replacement, one would 
still want to separate UI and logic. After all this is one of the most 
important improvements over the C++/.ui approach: clean separation, UI 
depending on logic, not the other way around.

Cheers,
Kevin

-- 
Kevin Krammer | kevin.krammer at kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5918 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131115/0d02a993/attachment.bin>