[Development] QML and JavaScript extensions

[Kevin Krammer]

On Friday, 2013-11-15, 11:51:43, Alan Alpert wrote:
> On Fri, Nov 15, 2013 at 2:00 AM, Kevin Krammer <kevin.krammer at kdab.com> 
wrote:
> > On Thursday, 2013-11-14, 21:20:25, Topi Mäenpää wrote:

> >> I considered the options carefully before switching to Qt5. I talked to
> >> Digia engineers and they told me the same you are telling now: QtScript
> >> will be deprecated and definitely not accessible from QML. Therefore, it
> >> was completely out of question. I don't think building anything serious
> >> on a deprecated API is a good idea anyway.
> > 
> > That could have been a miscommunication. What they probably meant was that
> > the standard QtQuick module would not have a QML type for QScriptEngine.
> > 
> > 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.
> 
> I think he's talking about JS integration into QML. It's the difference
> between MyObject {
>     prop: Math.min(alpha.foo, beta.bar);
> }
> and
> MyObject {
>     prop: "Math.min(alpha.foo, beta.bar);"
> }

Sure, but I think that this is the cause of the problem. Trying to do 
something different in scope than what was done before and expect the same.

> Sure, you can do the latter. Maybe even query the QQmlContext for
> evaluating unrecognized symbols such as alpha.foo. Then you start to
> reimplement binding logic and you start asking yourself "why am I
> doing this again?".

I would imagine that it would work almost exactly like in the situation 
without QML.
The script engine gets functions and object as part of its initialization and 
it uses them.

I.e. if I have an object in C++

QWidget *someObject ....

I register it with QScriptEngine like this

scriptEngine->newQObject(someObject);
// and then provide a name for it.

the equivalent QML would probably look like this

ScriptEngine {
  objects: [
    ScriptObject {
      name: "someNameUsedInScript"
      object: idOfSomeQMLObject
    }
  ]
}

> >> 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.
> > 
> > I also wouldn't consider widgets to be deprecated, at least not yet. And
> > nicely use QML with widgets as the UI elements, it is not replacing one
> > with the other either (though you probably meant QtQuick when you wrote
> > QML there).
> Yeah, QML doesn't deprecate widgets - it deprecates .ui files because
> now you can construct your widget UIs in QML :D

Exactly! :)

> Assuming you meant QtQuick there: Qt Quick-based development, even
> Components IMHO, is expected to take over for future *style* of UIs
> (I'd say mobile, but then take a look at Windows 8...). I expect
> "Classic" style UIs will continue to use widgets until Qt 6 at the
> earliest.

Right.

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/fc4bc765/attachment.bin>