[Development] QML and JavaScript extensions

[Alan Alpert]

On Thu, Nov 14, 2013 at 8:01 AM, Topi Mäenpää <topi.maenpaa at intopii.com> wrote:
> On 11/14/2013 04:43 PM, Robin Burchell wrote:
>> On Thu, Nov 14, 2013 at 3:08 PM, Topi Mäenpää <topi.maenpaa at intopii.com> wrote:
>>> Or rather could, if the interface wasn't a moving target.
>>
>> If an interface is a moving target, that means that trying to promise
>> compatibility for it is generally a bad idea.
>
> I don't quite get this. Can you elaborate? I was trying to say that the
> stuff I'm trying to do is doable in principle as proven by the couple of
> different implementations made so far. But every new release of Qt makes
> me hold my breath because I know I have used features that aren't
> promised to be available.
>
>> Once something is made public, you're stuck with it. For a very long
>> time, and maybe even forever if people get too attached to it. You
>> can't go back on that, so you need to be very, very sure you'll be
>> happy with it. As evidenced by the v8 to v4vm change, we aren't there
>> yet. And once we do expose it, we tie our hands from making future
>> changes that might be in our benefit.
>
> This is true, but also a common excuse. I have seen it being used to
> block quite a few feature requests in many projects. Now, however, we
> already have a pretty good API definition: QScriptEngine already
> provided just about everything that was needed. All those things are
> doable in v8, and I bet also in v4vm. It is just a matter of writing a
> few interface classes that hide the implementation details. That would
> free extension developers from the burden.

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.

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.

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.

--
Alan Alpert