> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
