[Development] QML and JavaScript extensions

[Alan Alpert]

On Thu, Nov 14, 2013 at 11:20 AM, Topi Mäenpää <topi.maenpaa at intopii.com> wrote:
>> Pick the wrong interface classes, like QtScript did, and you suffer in
>> the long term. That's why we aren't committing to anything more than
>> the overly basic QJSEngine API just yet.
>
>
> This is true for all new features. Fearing mistakes however means no
> innovation and no progress. But of course all new features need to be
> planned well and priorized. What I'm trying to achieve is to explain why
> this is an important issue and hopefully raise its priority so that it will
> be implemented soon.

Find the JIRA task and vote ;) .

>
>> As I understand it, the long term plan is to extend the QJSEngine APIs
>> and drop QtScript (and add QtWebEngine). Then for application
>> scripting purposes you can use QML/JS for QObject integrated scripts
>> or generic JS and it will work for the cases previously fulfilled by
>> QtScript (and use QtWebEngine for HTML5/JS scripts). V4 integrates
>> better with Qt than V8 did, so as an application scripting addition to
>> the Qt framework it does have better potential (and QtWebEngine will
>> have access to the platform browser's JS engine if you need something
>> for big scripts with no or minimal application integration). Ways it
>> integrates better includes: Faster for jumping in and out of JS,
>> faster when dealing with Qt types, runs on all platforms Qt does,
>> potential for better Qt Creator debugging and of course tighter QML
>> integration. So providing a JS engine for application scripting is
>> less of an "afterthought" and more of a "second stage" once we finish
>> the QML engine rewrite.
>
>
> I haven't been following the long term plans closely, but I believe this
> holds true for v4vm. In the current v8 implementation, however, QJSEngine is
> practically useless. It cannot be extended, and it even makes references to
> QML in the source code.
>
>> But that's a long term plan, v4vm isn't even released yet (new in 5.2
>> remember) and there's still tons of work to do. Until v4vm is ready to
>> take over from QtScript, which will still be a while, I believe the
>> recommendation is to keep using QtScript. It's deprecated and "done"
>> because we've reallocated development priorities, but until we've
>> finished its replacement it is your best option. Even though it means
>> using old or no QML, it sounds like the JS support is more important
>> for you.
>
>
> 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.
>
> 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. Otherwise, it
> is difficult to extend the functionality of UI applications. Since Qt is a
> UI toolkit after all, I believe most Qt applications have an UI.
>
> Anyhow, I understand that your resources are limited and this isn't going to
> be implemented this week. But can I count on v4vm being the script engine
> used for the foreseeable future? If yes, is there an API documentation so
> that I could familiarize myself to the internals? The v8 interface was
> pretty straightforward stuff so I believe porting the code to v4vm isn't a
> huge deal either. But without documentation it'll take a lot longer.

v4vm is better documented than v8 (still not really "documented"
though), and will probably be in use until Qt 6 (if only because I
expect we'd bump the major version if we switched again :P ). While I
do expect v4vm to be used for the foreseeable future it's still young,
and immature, and that means change. Especially since we have total
control and we need to take advantage of that lack of public API as
much as possible ;) .

But at least the creators are still around, unlike the other engines.
Hopefully they'll add some insight when they wake up, and you can
always ask questions in #qt-v4vm on freenode (CET hours at least).

--
Alan Alpert