Quote Originally Posted by mfojtak View Post
The C++ function is obviously an option. But it would not allow me to define the connections declaratively as with "onSignal: codeToExecute".
Of course you can define connections in a declarative manner. It's just a matter of exposing a proper interface from C++ to QML.

I need the direct connections for what they are exactly for - connecting slots directly. I developed a real-time application which is performance critical. The queued connections bring an overhead with copying slot arguments, queue slot arguments.
Khem... QtQuick is not really designed for time critical tasks. Queued connections are the least of your problems.

Also, I need the slot to run under the same thread as signal owner.
I'm not even going to explain now what that is Wrong(TM).

My application is a kind of dataflow/workflow application. Each module/building block is represented by a QObject which are interconnected via signals/slots.
I've created an XML configuration file for it. However, it would be much better to utilize QML, which is declarative, it allows me to embed a Javacript code - well you know benefits of QML :-)
QML (in Qt5) can be used without QtQuick as a way to define relations between objects. However its work ends after the QML tree is parsed and all functionality is embedded in the object types you expose from C++. You can expose an alternative for Connections that will make direct connections however be aware that writing slots directly in QML scripts has its limitations. Because they are executed by the script engine, they are limited to a single thread (as the script engine itself cannot be called from multiple threads). If there are objects behind the scene that live in other threads, trying to invoke script code from such thread will simply crash your program.

Either way, using JavaScript with garbage collecting, JIT compiling and all that stuff for time critical tasks is very likely bad design.