[Development] QML and JavaScript extensions

[Kevin Krammer]

On Friday, 2013-11-15, 23:04:40, Topi Mäenpää wrote:
> > 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.

The QML engine only interprets the QML code and potentially embedded JS code. 
It wouldn't interpret the other JS engine's code, that would of course be 
ridiculous.

I don't see any problem with running some code in C++, Go,  a script engine, 
what not, though.

> > 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.

My understanding is that the object emitting the signal does not care if it 
has one receiver or two, nor whether the receiver invokes C++ code or a script 
function.

My understanding is further that the QtScript engine does not care how the 
object was created when it gets added to its context, i.e. whether it was 
created with hardcoded new, or loaded by QUiLoader or, in this case, 
instantiated by the QML engine.

But I will try to write an example program that instantiates a QWidget in QML 
and see if the QtScriptEngine can still use it the same way as when it is 
created by hardcoded new.

> 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.

True. If QJSEngine is defined to be fully ECMA compatible then that is of 
course possible.
I was primarily working under the impression that while QJSEngine was intended 
to replace QtScriptEngine, the need for V4 made that less likely.

> >> 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.

We will have to disagree there. I consider the UI to be replacable, as free of 
application logic as possible.
In that model QML instantiates objects and connects/binds them. 

I understand that there is a different approach, basically creating 
applications like webapps. Do all processing in the UI, only use components 
for visualization and platform integration.

> 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.

Ah, I see. The problem is that the QtQuick items are not instantiable from 
C++. Good point.
Not sure it is really necessary to directly create UI from inside the 
application code, but I can imagine that this something that one would at 
leasst like to be able to support.

> Separating "business logic" and UI has not much to do with this. You can
> do it well or worse with any technique.

Sure. QML just makes the separation very obvious. Since it is declarative you 
immedately see when you are going imperative.
If you are all imperative it is hard to tell which part is UI and which is 
application core.
With QML you can see that you are doing something wrong when your imperative 
"QML code" starts processing actual data, like file content or network 
response.

Cheers,
Kevin
-- 
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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5918 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131115/c5d61294/attachment.bin>