On Thu, Nov 14, 2013 at 9:31 AM, Thiago Macieira <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
