> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
