[Interest] QtScript to QJSEngine migration

[Ilya Diallo]

Hi Julien,

A long thread on this list last march on this subject was concluded by
an answer from Frederik Gladhorn (copy below). For now (5.5), the best
is probably to postpone your migration if you want to avoid
"unofficial" workarounds. QtScript is not going anywhere until feature
parity is (more or less) achieved, with a porting guide for
incompatibilities.
Your proposals could be part of a porting documentation, though.

Ilya.


> Hello all,
>
> thanks for all the feedback, it's very much appreciated.
> The discussion has sparked quite a few discussions here in Oslo and we see
> that we have some way to cover when it comes to getting QJSEngine up to the
> level of what QtScript offers currently.
>
> We think being able to run non-gui applications is important, that's why we
> have a clean separation between the QML and Quick libraries. Using only the
> QML library there are no UI dependencies and QJSEngine is available as a pure
> JS engine without forcing any QML on anyone.
>
> We still think it's the right way forward - maintaining one engine and keeping
> it running well, instead of trying to deal with JSC, see Thiago's mails for
> the reasoning behind that (plus the one in WebEngine which is unrelated to
> this discussion).
>
> The deprecation is just the label that reflects reality for QtScript. There is
> no work being done on the module actively.
>
> The focus will now be to get the missing features in place in QJSEngine. Most
> of them hopefully by the time of the 5.6 release, to get the offering on par.
> It would be helpful to get a list of features that really need to be there,
> currently from what I understand the most urgent ones are:
> - instantiating QObjects from JS
> - exposing individual native functions to JS
> - debugging API
> The good thing is that a lot of the work is already done in QJSEngine, it's
> simply not exposed in the API yet.
>
> To re-iterate: QtScript is not going away, especially not before we have a
> full replacement including more porting documentation. But don't expect active
> development of the module to happen either. For many simple use cases,
> QJSEngine can act as drop in replacement by the way, so we do care about the
> migration path and try to keep API compatible where it is possible.
>
> Greetings,
> Frederik


2015-06-22 17:17 GMT+02:00 Julien Cugnière <julien.cugniere at gmail.com>:
> Hi all,
>
> With QtScript deprecated in Qt 5.5, and likely removed in a future
> version, I'm looking at how to migrate to QJSEngine. There are some
> things I'm not sure how best to achieve with the new minimalist API :
>
> 1. Exposing a global function to Javascript from C++.
>
> In QtScript, one could write a C++ function with the signature "
> QScriptValue f(QScriptContext*, QScriptEngine*) ", and expose it
> directly in a global variable. I found no equivalent in QJSEngine. If
> I understand correctly, I can only expose QObjects, so the best I
> could come up with is the following :
>
>  * write my functions as Q_INVOKABLE members in a QObject.
>  * expose that QObject using QJSEngine::newQObject.
>  * iterate over the object with QJSValueIterator, and copy the
> function properties to the global object.
>
> Is there a better way available, or planned ? If not, would a merge
> request to add the above to the documentation be accepted ? (probably
> somewhere in "Making Applications Scriptable").
>
> 2. Writing a variadic function from C++.
>
> In QtScript this could be done with the QScriptContext* parameter.
> With QJSEngine, the best I've come up with is this :
>
>  * write a wrapper function in javascript forwarding the "arguments" object :
>    " function foo() { return Foo.foo_impl(arguments); } "
>  * write foo_impl in C++ as a Q_INVOKABLE member taking a single
> QJSValue parameter.
>
> Is there a better way ? And again, is this worth adding to the documentation ?
>
> 3. How to raise a Javascript error from a function implemented in C++.
>
> This is basically https://bugreports.qt.io/browse/QTBUG-39041, which
> has seen no comment for the past year. Is something similar planned ?
> Otherwise the only solution I see is again a wrapper function written
> in Javascript. Something like this :
>
>     function foo() {
>        var res = foo_impl();
>        if (Object.getPrototypeOf(res) === Error)
>             throw res;
>        else
>            return res;
>     }
>
> --
> Julien Cugnière
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest