On Nov 11, 2013, at 3:38 AM, Topi Mäenpää <[email protected]> wrote:
> V8 was touted as the unifying solution for Qt JavaScript support. It > really would have made sense to use the same script engine everywhere. I > feared that the script engine would be changed once again and discussed > with Digia guys before switching to Qt5. The message was clear: QtScript > will be deprecated and QML with V8 is the future. This seemed to be a > sure bet, and the pointer to QV8Engine was even available through > QJSEngine::handle(). I don’t know who exactly “touted” it, since (and developers, please correct me if I’m wrong) Qt 5.0 and 5.1 uses a heavily modified version of V8. Thus webkit and QML in Qt 5 had two completely separate JavaScript engines, and in Qt 5.2 they still do, except that now QML’s engine doesn’t derive from V8 anymore. I can’t understand why would that ever be a problem, since, due to modifications needed for QML support, the possible ways to extend V8 from QML are different from extending V8 merely from webkit. Both Qt and webkit’s javascript engines are implementation details - it’s fairly obvious from the exposed APIs. I personally think that the “touting” you allude to is merely the fog of war, I never saw it explicitly mentioned as a strategy for extensible, reusable general-purpose Javascript engine functionality. Personally, I think that if you want JavaScript in any application, Qt-based or not, you have to choose an engine that will work on the platforms of your choice and for your purposes, and stick to it - meaning it’s on you to integrate it. Note that V8 is out of the question on many app stores due to sandboxing requirements. If you want your platform to be usable on the ever-more-powerful mobile platforms, that needs to be kept in mind. Cheers, Kuba Ober _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
