[Development] Clarification needed for Qt Script's future over QJSEngine/Value
Simon.Hausmann at theqtcompany.com
Wed Nov 26 20:15:20 CET 2014
You are right, we need to add a few more features to QJSEngine.
I'm not so much in favor of the default prototype for meta type api anymore, as it promotes the creation of slow conversion code I think. If you peek at my gerrit dashboard then you can see that I'm about 80% done with a series for gadget support that will allow you to expose your own value types without a conversion needed.
In theory we could build that up with some help from moc to the extend that the jit accesses your Q_PROPERTY members directly.
I'm hesitant to expose engine internals because that really hurt us last time. But I'm all in favor of adding some of the qml extension js APIs by default, such as qlocale extensions etc.
There's some low hanging fruit there, so contributions are welcome :)
From: N. N.
Sent: Wednesday, November 26, 2014 19:51
To: development at qt-project.org
Reply To: N. N.
Subject: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
I was looking at using QtScript for a project and noticed that all work has been "ABANDONED" for using the new java script engine V8 as noted in http://qt-project.org/wiki/V8_Port and
The talk is that for Qt5 there is QJSEngine/Value API instead, but, that is a smaller subset of features over what QtScript offers now.
Reading about QJSEngine/Value there seems to be no official API way for exposing a C type callback, so everything has to go through QObject bindings instead, correct?
Does this mean that QtScript will eventually be deprecated in favor of QJSEngine/Value since
QtScript will not be updated any longer with any improvements and basically be left in a "as is" state with possible bug fixes?
Development mailing list
Development at qt-project.org
More information about the Development