[Development] QML and JavaScript extensions

[Knoll Lars]

On 16.11.13 00:26, "Alan Alpert" <416365416c at gmail.com> wrote:

>On Fri, Nov 15, 2013 at 2:17 PM, Kevin Krammer <kevin.krammer at kdab.com>
>wrote:
>> [...]
>>> 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.
>
>V4VM is intended to be a fully ECMAScript compatible JS engine (I
>think it's there already even, for the first release!). The special
>needs of QML are either in performance profile, or only in the "QML"
>parts of QML/JS. AFAIK, the plan (no more long-term than when we were
>using V8 ;) ) is still for QJSEngine to expose a full ECMAScript
>compliant JS engine for application scripting, similar to QtScript but
>QML integrated and avoiding running a second JS engine.

Yes, v4vm in QtQml/5.2 is fully compliant with EcmaScript 5.1. It¹s
actually much more standards compliant than QtScript is (QtScript does
e.g. Not support strict mode).

And yes, the plan is to add APIs to the QJS* set of classes to make it a
full replacement for Qt Script in the future. We¹re not there yet. I
hope/believe that we can add some of the missing API with 5.3 (as the
internal data structures in the JS part of the engine start to settle
down).

>>> >> 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.
>
>It's more complex than that, because the split between UI logic and
>application logic can be hard sometimes, especially when the multiple
>UIs aren't exposing the exact same functionality. (Obviously they
>expose the same core functionality, but maybe the enterprise edition
>has more cowbell?)

Basically you have the whole range at your disposal. Qt is not there to
limit you as an application developer or push you into one way of doing
things. While some things could be considered best practice, I believe one
of the main strengths of the framework is that application developers have
a large degree of freedom and can choose the tools that match the task at
hand. So you can do your app fully in C++ using widgets, use QML only as a
thing layer on top of C++ app logic, or push a lot or even all of your
logic into JS. 

But as with any tool there are limits. Some things do (and probably always
will) require C++, while some others can be most easily achieved through
QML. The reason for this is that the problem of creating fluid user
interfaces is rather different from the problem of creating the
application logic. 

Cheers,
Lars

>
>The intended approach, for a JS/QML app with C++ extensions, is that
>the UI and UI logic are in JS/QML, the application logic is still in
>C++, but it's exposed through reusable modules. So some stuff that's
>on the edge moves from "application" logic to "ui" logic. As an
>example, take storing high scores in SameGame. Current model is that
>it's application logic (NB, samegame has the app logic in JS) but with
>a "HighScores" module encapsulating that logic, it could move out of
>the JS files and start using that module from QML directly as passing
>the score to the "logic module" is UI logic. The advantage here is
>that new UIs can bring in modular secondary functionality easily, like
>web highscores or time-decay highscores, without needing to touch the
>application logic. Sorry I don't have a very clear example/story here,
>as I said we're not up to this point for realistically sized apps ;) .
>
>--
>Alan Alpert
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development