Re: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
On Friday 28 November 2014 05:08:43 Kevin Kofler wrote: Thiago Macieira wrote: Since Qt doesn't use V8 anymore, there should not be any clashes at all. Be warned though that QtWebEngine does use V8 through Chromium. Which means that lots of archs will not be able to have QtWebEngine. -- Trabaja como si no necesitaras el dinero. Ama como si nunca hubieses sido herido. Baila como si nadie estuviera mirando. Canta como si nadie escuchara. Vive como si fuera el Cielo en la Tierra. Anónimo Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
Thiago Macieira wrote: Since Qt doesn't use V8 anymore, there should not be any clashes at all. Be warned though that QtWebEngine does use V8 through Chromium. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
Hi, 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 :) Simon Original Message From: N. N. Sent: Wednesday, November 26, 2014 19:51 To: development@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 then pouring over other bug reports the mailing list about QtScript and how QtScript won't be updated to use a newer JavaScriptCore since it would be too much work to maintain. 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
On Wednesday, 26 November 2014, 14:15, Hausmann Simon simon.hausm...@theqtcompany.com wrote: Hi, 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. I am wondering if just going directly to V8 instead of using Qt as the middle man would be the best course of action, that way you get all the speed benefits that V8 offers, and no need to mess with any conversion code, with the only disadvantage, that I can think of, is adding another dependency. Or, will this introduce linker errors with Qt's version of V8, if all we need is QtCore.lib QtGui.lib? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
On Wednesday 26 November 2014 19:59:55 N. N. wrote: On Wednesday, 26 November 2014, 14:15, Hausmann Simon simon.hausm...@theqtcompany.com wrote: Hi, 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. I am wondering if just going directly to V8 instead of using Qt as the middle man would be the best course of action, that way you get all the speed benefits that V8 offers, and no need to mess with any conversion code, with the only disadvantage, that I can think of, is adding another dependency. Or, will this introduce linker errors with Qt's version of V8, if all we need is QtCore.lib QtGui.lib? Since Qt doesn't use V8 anymore, there should not be any clashes at all. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
