[Development] Clarification needed for Qt Script's future over QJSEngine/Value

[N. N.]

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?

[Hausmann Simon]

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: ***@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?

[N. N.]

Post by Hausmann Simon

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?

[Thiago Macieira]

Post by N. N.

On Wednesday, 26 November 2014, 14:15, Hausmann Simon

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.

[Kevin Kofler]

Post by Thiago Macieira
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

[Lisandro Damián Nicanor Pérez Meyer]

Post by Kevin Kofler

Post by Thiago Macieira
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/

[Kevin Kofler]

Post by Lisandro Damián Nicanor Pérez Meyer
Which means that lots of archs will not be able to have QtWebEngine.

Right. This is one of the many problems of QtWebEngine and its Chromium
dependency. (It will affect the Fedora secondary architectures, too.)

If you want to know the others:
* bundling of Chromium by QtWebEngine,
* bundling of many libraries by Chromium (and thus transitively by
QtWebEngine),
* lack of integration with the system and even Qt itself, e.g.:
- we lose QNetworkAccess, which allowed making QtWebKit use KIO (see
KWebKitPart) – Chromium hardcodes its network access code instead. This
also means no support for man:, info:, gopher: etc. protocols, unless
they get implemented as Chromium plugins (but last I checked,
QtWebEngine also didn't support those).
- no GStreamer support. (Direct FFmpeg use is a PITA for distributions to
deal with.)

We are not even sure we will be able to import QtWebEngine into Fedora at
all, because of the bundling and FFmpeg issues. (So far, nobody has dared
even trying to submit it for review.)

Kevin Kofler