kevin.krammer at kdab.com
Fri Nov 15 21:25:39 CET 2013
On Friday, 2013-11-15, 21:51:37, Topi Mäenpää wrote:
> > 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
> > 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
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.
UI not being scriptable itself.
You would still have that if QML used Lua.
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
> (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
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.
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...
Size: 5918 bytes
Desc: not available
More information about the Development