topi.maenpaa at intopii.com
Fri Nov 15 22:04:40 CET 2013
> That could have been a miscommunication. What they probably meant was that the
> standard QtQuick module would not have a QML type for QScriptEngine.
I didn't need to be told this. I mean, who would really suggest having a
I really was calling Python code.
> QScriptEngine can certainly be accessed from QML. Sure evaluate is currently
> neither a slot nor a Q_INVOKABLE, but that would easily added and/or worked
> around by a simple subclass or wrapper.
> Remember that any default constructible QObject class can be instantiated by
> QML, its slots, signals, properties and Q_INVOKABLEs becoming available.
> QML is just the "glue" between object instances, it doesn't care what those
> objects do internally.
If you think of it for a while, you may notice that neither writing
wrappers for all types nor passing code as text to be evaluated by
another JS engine wouldn't be a brilliant idea. Just figure how a signal
from a C++ class would be passed from one engine to another.
Quoting your latest post:
> 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.
The engine that runs QML implements the ECMAScript standard and it must
have all the necessary tools for extending JS with C++. Otherwise, it
could be used to implement neither QML, the extensions QML already has
added to ECMAScript nor ECMAScript itself. The lack of a public API to
these features is the only reason I need to do the shoehorning every
time the engine is changed.
>> replaced by QML. In this situation, a good extension interface to the
> I have to disagree with a couple of items here.
> heading into using it. As for JS in QML, any sensibly designed application
> will avoid doing business logic process in the UI. That was already not a good
> idea when using C++, no need to continue bad practise when the new UI
> technology hands you a nice way to correct that.
In Qt4, widgets were still the main UI technology. Nowadays, widgets are
"deprecated". (I'm putting quotes due to the comments to my last post,
but it is really not hard to see where the development is heading.)
support for C++ applications, but applications were not based on it.
extensions. Therefore, I'm sticking to my statement: a good extension
interface is an important feature.
There are tons of things that cannot be done in QML but are easily done
with the underlying JS engine (sans the public API). Like registering
types dynamically. qmlRegisterType() needs to know the exact type at
compile time, but you can easily add new constructor functions to a JS
scope at run time. QML components don't have accessible constructors and
cannot thus be extended by altering their prototypes, which is a
standard JS programming pattern. You can't add "static" or instance
functions or properties to QML objects, but you can add them to
constructors using the JS engine. With the JS engine, you can implement
functions with a variable number of arguments. And here I'm just
scratching the surface.
Separating "business logic" and UI has not much to do with this. You can
do it well or worse with any technique.
I was already answered that JS extensions are a planned feature, but
that I have to live with the status quo for a while. Fair enough.
+358 40 774 7749
More information about the Development