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 | [email protected] | 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
