Qt World Summit: Register Today!

QQmlEngine as a replacement of QtScript for non-gui tasks

  • Since QtScript and QtScriptTools are deprecated, I want to port my apps to QtQml. QQmlEngine with the out-of-the-box-support of "import" commands (a feature that I've implemented myself for QScriptEngine) and with QtCreator as editor and debugger tool seems to be the right way. I've still some questions:

    1. I am not using scripts für UI. Ui is still based on QtWidgets. Instead, I'm using scripts (with a lot of imports) for long lasting tasks and calculations. Because the QScriptEngineDebugger of QtScriptTools does not work with a QScriptEngine that lives in another thread than the GUI thread, my script engine lives in the GUI thread. The GUI keeps responsive due to a positive value passed to QScriptEngine::setProcessEventsInterval(int). How does QQmlEngine behave? Is it possible to move QQmlEngine to a separate thread and still to debug script code with QtCreator?

    2. Instead of moving QQmlEngine to a separate thread, I could use WorkerScript (by the way, WorkerScript is part of QtQuick and not QtQml, why?) but with WorkerScript, the .import command is not available :-( But Qt.include could be an alternative, is this available in WorkerScript?

    3. If the answer is "Moving a QQmlEngine to a separate thread is not a good idea, just use WorkerScript, but WorkerScript cannot import or include any other files" then I'm not really sure how to port from QtScript to QtQml. Do you have some idea how to use QQmlEngine for complex non-gui tasks (with a lot of imports) without blocking the UI?

  • Lifetime Qt Champion


    IIRC, there's been recently some discussion about QQmlEngine and QtScript on the interest mailing list You should go there take a look.

  • Hi SGaist,

    thank you for the hint. I've found this post in the mailing lists: http://lists.qt-project.org/pipermail/interest/2015-March/015971.html written by the Qt Developer Frederik Gladhorn. It is very interesting, especially these two parts:


    The focus will now be to get the missing features in place in QJSEngine. Most of them hopefully by the time of the 5.6 release, to get the offering on par. It would be helpful to get a list of features that really need to be there, currently from what I understand the most urgent ones are:

    • instantiating QObjects from JS
    • exposing individual native functions to JS
    • debugging API

    The good thing is that a lot of the work is already done in QJSEngine, it's
    simply not exposed in the API yet.

    Part 2

    To re-iterate: QtScript is not going away, especially not before we have a full replacement including more porting documentation. But don't expect active development of the module to happen either. For many simple use cases, QJSEngine can act as drop in replacement by the way, so we do care about the migration path and try to keep API compatible where it is possible.

    I don't understand why this important message is not part of the documentation, at all places where one can read that QtScript is deprecated. It would be very helpful for all the QtScript users.

    What does it mean for me now? Try to port to QQmlEngine or wait for an extended QJSEngine? In fact, I don't have fully understand the differentiation of both engines. Both can be used without any dependencies to UI libraries, all the features of QJSEngine are also available for QQmlEngine and even more, QQmlEngine comes with support for import statements and QtCreator as script debugger. Why should I prefer QJSEngine to QQmlEngine?

  • I've written a test program, that creates a QQmlEngine either in the GUI thread or in a separate thread. Breakpoints in the script code are working only when the QQmlEngine lives in the GUI thread.

    So, I can answer the first question in my first post:
    Unfortunately, it is not possible to debug script code with QtCreator when QQmlEngine lives in another thread than the GUI thread.

    That means, I've to use WorkerScript, because a member similar to QScriptEngine::setProcessEventsInterval(int) is not available. But WorkerScript has the disadvantage that it creates a new context for the script that is executed in a separate thread. So, access to properties, methods and other attributes of the qml item is not possible.

  • Lifetime Qt Champion

    Did you take a look at the mailing lists ? IIRC there's a thread about QtScript/QQmlEngine not so long ago and you could voice your interest there

  • Hi SGaist,

    of course, I've taken a look to the mailing lists. Did you read my second post?

    I've modfied my test program and can answer the second question of my first post now. The .import syntax does not work in WorkerScript, as documented. But Qt.include works well.

    Unfortunately, it is not possible to set breakpoints in that part of code, which is executed by WorkerScript in a separate thread.

    In the end: It doesn't matter whether the complete QQmlEngine lives in a separate thread or only a part of script code is executed in a separate thread (via WorkerScript), once the script runs in a separate thread, debugging with QtCreator is no longer possible.

  • Lifetime Qt Champion

    Yes I did, but somehow i've mixed that with the bug report system. Anyway, what I meant is that you should continue the discussion started there to include your current concerns in order to possibly improve your situation

Log in to reply