[Development] QML and JavaScript extensions

[Topi Mäenpää]

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

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

Regards,
-- 
Topi Mäenpää
Co-founder, Intopii
+358 40 774 7749