[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