How to access v8's debug API in QJSEngine

[anda_skoa]

That's unlikely as two different engines would have to be maintained simultaneously.

True, I also don't find that likely. Too bad though, having a high performance engine available would have been nice and that was probably even the original intent.

I'm afraid that QScriptEngine will have to bite the dirt first and there will be no replacement in place that would provide decent in app debugging capabilities.

Well, "first" in this context still means Qt6, it is more likely that QJSEngine's internals will change earlier than that.

Ideally QQmlEngine would have used QJSEngine and so it could switch to something else while keeping QJSEngine and deprecating QScriptEngine.
But alas it derives from it, so unless QJSEngine is two different things internally (very unlikely!), it will become an engine optimized for the QML use case.

My take is that the needs for in-application scripting, especially due to the easy way of accessing application provided infrastructure from scripts, can easily be fulfilled by QScriptEngine.

Of cause one could hope they will get rid of QJSEngine all together, keep QScriptEngine for scripting and use v4vm only for QQmlEngine.

While they obviously can't get rid of QJSEngine as a class, my guess is that it will become an implemetation detail of QQml and QScriptEngine stays the main in-application scripting facility.

on a side note: qml and webkit, i haven't looked into it in detail, but are they actually deploying v8 code twice once as part of qml and once as part of web kit? Thats not elegant, there should be a shared v8 library used by all modules.

WebKit is special, its Qt "frontend" is part of the WebKit, not WebKit part of Qt. So it is more a separate project that is being worked on by some developers who also happen to be developers on Qt-Project.org

WebKit might also switch to a different JS engine at some point.

Regarding QML:

a QML document describes a tree of element, much like XML but with less verbose syntax. Each element type is specified either by another QML document or a C++ class registered with the QML type system. The requirement for the latter is that the class derives, directly or indirectly, from QObject and that it can be created without arguments.

As Qt developers we often create trees of QObjects, e.g. QWidget trees, QStateMachine with nested states, etc.
QML can be used to do that in a less hard-coded fashion, e.g. if the tree in question needs to be changable without changing the binary.

Since all nodes in such a tree are essentially QObject instances, they have the capability of signals, slots and properties. QML allows to call slots, connect to signals and read/write properties. One really nice feature is that properties can not only be assigned a fixed value but an expression containing other properties and that expression is automatically reevaluated whenever one of its contained properties changes its value.

The latter is of course especially nice in UI code, where e.g. a button's enabled state often depends on some other UI element's content.
But it can be useful for other object hierachies as well, it is mostly a matter of getting used to this form of state propagation.

Cheers,
_