[Development] QML and JavaScript extensions

[Alan Alpert]

On Thu, Nov 14, 2013 at 9:31 AM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On quinta-feira, 14 de novembro de 2013 17:25:08, Tony Van Eerd wrote:
>> > 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.
>>
>> Where do value-types (ie non-QObject, copyable, etc) fit into the plan?

Definitely in the plan. The long-term plan, it's not yet on the radar
for exactly when it might happen. But we've needed it internally a lot
already for good APIs, and so we know it's needed (and we know the
internal APIs aren't good enough yet ;) ). The example I like is how
the particle system can expose individual particles for manipulation
in JS without the insane overhead of creating thousands of extra
QObjects. Since QtQuick.Particles is obviously not a built-in language
feature, it demonstrates that 3rd party modules need this API but alas
we currently only have the private APIs (quite risky to use if you
aren't inside the qtdeclarative repository).

>> I find that forcing classes to be QObjects just to make them QML accessible
>> really denigrates some API designs. Any advice?
>
> Value-type classes need adaptation to work in QML. Make them sharable,
> copyable, whatever is needed, then we need to figure out how to make QML
> understand them.
>
> The metatype system is a start, since it can manage those types' lifetime. I
> think it can even compare them for equality these days.
>

Using QObjects is certainly the easiest path, and will probably
continue to be the only path for some of the more advanced QML-only
usecases (grouped properties and attached properties come to mind).
But there are cases where it's worth filling out an adapter to avoid
having to subclass QObject, especially since the adapter should have
no per-instance cost. So *long-term* I would expect a public value
type API, which would probably work with straight JS as well as
QML/JS. Unless QObject becomes free per-instance ;) .

PS: One feature on the list for the "qml" runtime is to just run
straight JS files in v4:
https://bugreports.qt-project.org/browse/QTBUG-34852 . Missed the 5.2
timeframe though.

--
Alan Alpert