[Development] QML and JavaScript extensions

Topi Mäenpää topi.maenpaa at intopii.com
Fri Nov 15 20:51:37 CET 2013

> 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.

> 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.

> 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.

> Please correct me if I am wrong, but the issue you have with keeping doing
> what has proven to be a good way is the "deprectated" label QtScript currently
> has.

I'm afraid I need to correct you. It makes absolutely no sense to run 
two different JS engines that communicate with each other through a 
bunch of C++ glue code.

> 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.

Topi Mäenpää
Co-founder, Intopii
+358 40 774 7749

More information about the Development mailing list