[Development] QML and JavaScript extensions

[Topi Mäenpää]

> 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 
JavaScript engine inside a JavaScript engine? I could see the reason if 
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.

>> Qt is heading to a JavaScript-based future. Widgets are deprecated and
>> replaced by QML. In this situation, a good extension interface to the
>> JavaScript engine that runs QML is a really important feature.
>
> I have to disagree with a couple of items here.
>
> Qt has already had JavaScript based scripting support for ages, so it is not
> 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.) 
Prior to QML apps, JavaScript has been a tool to provide scripting 
support for C++ applications, but applications were not based on it. 
Now, the situation has turned around: JavaScript/QML app, C++ 
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.

-- 
Topi Mäenpää
Co-founder, Intopii
+358 40 774 7749