Direct connection in QML

Hello,

I am connecting QML object signal to a slot like so:

Code:

---

onSignal: slot

---

It creates

Code:

---

Qt::QueuedConnection

---

between the two objects.
But I want to create

Code:

---

Qt::DirectConnection

---

between them.

How can I achieve it? Or is there a code in QML engine that I can tweak?

Thank you.

Michal

Your question is ambiguous! can you make a simple example?

Quote:

---

Originally Posted by mfojtak

How can I achieve it?

---

I don't think you can do it directly. In theory you could expose a C++ function to QML where you'd do the connection on C++ side but it wouldn't be as simple to use as "onSignal: codeToExecute".

Why do you need that?

The C++ function is obviously an option. But it would not allow me to define the connections declaratively as with "onSignal: codeToExecute".
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.
Also, I need the slot to run under the same thread as signal owner.
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 :-)

Quote:

---

Originally Posted by mfojtak

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.

Quote:

---

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.

Quote:

---

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).

Quote:

---

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.

Quote:

---

Khem... QtQuick is not really designed for time critical tasks. Queued connections are the least of your problems.

---

QtQuick is just a QML plugin. I want to use QML as a language to define an object tree of any QObjects. The app could be a deamon with no UI.

Quote:

---

I'm not even going to explain now what that is Wrong(TM).

---

What do you mean? That's what direct connections are for - slot is executed by the same thread which emits the signal.
Direct connections are used when necessary. The UI elements are connected with other parts by queued connections which makes sense because I don't want my UI to disrupt my real time part (UI runs under dedicated thread anyway).

Quote:

---

You can expose an alternative for Connections that will make direct connections

---

How is that possible?

Quote:

---

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

---

The application doesn't contain only time critical parts. Javascript gives user an extra flexibility. Let say I need to add some extra logging to my app. I can just write handler which will do logging in QML without recompiling my app. I am fully aware that Javascript handlers run under dedicated JS engine's thread.

I just need to have a choice which connection type to use. Real-world applications usually need both.

Quote:

---

Originally Posted by mfojtak

What do you mean? That's what direct connections are for - slot is executed by the same thread which emits the signal.

---

If your objects live in different threads then having direct connections between them is a good first step to the end of the world.

Quote:

---

I don't want my UI to disrupt my real time part (UI runs under dedicated thread anyway).

---

Qt does not bring any real-time guarantees. Regardless if you use direct connections or queued ones.

Quote:

---

How is that possible?

---

It's as possible as exposing any other QML element. "Connections" is by no means different.

Quote:

---

The application doesn't contain only time critical parts. Javascript gives user an extra flexibility. Let say I need to add some extra logging to my app. I can just write handler which will do logging in QML without recompiling my app. I am fully aware that Javascript handlers run under dedicated JS engine's thread.

---

And that logging has influence on when your time-critical part gets executed (or not).

Quote:

---

I just need to have a choice which connection type to use. Real-world applications usually need both.

---

You do have that freedom. You just need to enable it for yourself.

Quote:

---

If your objects live in different threads then having direct connections between them is a good first step to the end of the world.

---

The objects which I connect directly live in the same thread. But the code is executed by a new QThread that I create. This thread acts as a realtime timer which triggers the execution of slots which emit signals and other slots and so. This object graph is defined by a custom XML at the moment. Take a look at the project's (beta) website. It might help you to understand what I am after.

Quote:

---

Qt does not bring any real-time guarantees. Regardless if you use direct connections or queued ones.

---

Qt is only an application framework. The OS does bring real-time guarantees. I am using clock_nanosleep() kernel instruction in my C++/Qt timer code. It works great. My realtime part is not missing deadlines on sub-microsecond basis - but only if my modules (QObjects) are connected directly. With queued connections it doesn't even make sense to measure delays as you bring an extra queue in between my modules. That's why I need direct connections.

Quote:

---

It's as possible as exposing any other QML element. "Connections" is by no means different.

---

The Connections object is used as this. See the following example:

Code:

---

Connections {
     target: area
     onClicked: foo(parameters)
 }

---

Looking at the code above I can't see any way how to impact the connection type of clicked signal. I must be missing something. Should I inherit Connections class? I don't have problem with exposing a QML element. My problem is that the notation onSignal:slot always creates queued connection.

You have to implement your own element, say DirectConnections.

OK, let say I have implemented my DirectConnections object. Now I also have object called Sender which emits signal called signal. And I have object called Receiver with slot called slot(). All three objects are exposed by my QML plugin called CustomPlugin.
The QML would look like this:

Code:

---

import CustomPlugin 1.0
Sender {
   id: sender
}
Receiver {
   id: receiver
}
DirectConnections {
   target: receiver
   NOW HOW DO I CREATE CONNECTION BETWEEN onSignal and receiver.slot()   
}

---

The question is hidden in the code above. What shloud I do to implement such a class which would understand this: onSignal: receiver.slot() ?
I know you can do it with Connections object. But this object is part of QML language which parses "signal: slot" notation in a special way.
It would be brilliant if I could have custom object which keeps the same notation as Connection object. But how to implement it. Could you provide few lines of code which would illustrate it?

For example:

Code:

---

DirectConnections {
  source: sender.signal
  target: receiver.slot
}

---

I'm not sure how to access the signal and the slot itself from the C++ side. If you can't find a way to do it, you can always use separate properties for the signal and slot signatures (as strings) that you will then use in the backend.

More likely having two properties of type QObject* and two properties of type QString.
Once all four properties are set, code is triggered that does
1) lookup of slot and signal through QMetaObject
2) call connect with the two objects and the retrieved signal and slot signatures

Cheers,
_

---

Added after 8 minutes:

Ok, I have to say I don't understand the problem.

I get DirectConnection behavior in a simple test application

Code:

---

#ifndef TIMER_H
#define TIMER_H
 
#include <QObject>
 
#include <QtQuick>
 
class QTimer;
 
class Timer : public QObject
{
    Q_OBJECT
 
public:
    explicit Timer( QObject* parent = 0 );
 
signals:
    void timeout();
 
private:
    QTimer* m_timer;
 
private slots:
    void onInternalTimeout();
};
 
#endif // TIMER_H

---

Code:

---

#include "timer.h"
 
#include <QDebug>
#include <QTimer>
 
Timer::Timer( QObject* parent )
    : QObject( parent ),
      m_timer( new QTimer( this ) )
{
    m_timer->setInterval( 1000 );
    connect(m_timer, SIGNAL(timeout()), this, SLOT(onInternalTimeout()));
    m_timer->start();
}
 
void Timer::onInternalTimeout()
{
    qDebug() << Q_FUNC_INFO;
    emit timeout();
    qDebug() << "emit timeout() returned";
}

---

Code:

---

import QtQuick 2.0
import CustomComponents 1.0
 
Timer {
    id: timer
    onTimeout: console.log( "onTimeout in QML" )
}

---

Obviously exporting the Timer class with qmlRegisterType in "CustomComponents" version 1.0

Output is

Code:

---

void Timer::onInternalTimeout() 
onTimeout in QML
emit timeout() returned

---

So emit returns after the "QML slot" has been called. AKA DirectConnection

Cheers,
_

Quote:

---

Originally Posted by anda_skoa

More likely having two properties of type QObject* and two properties of type QString.

---

Yes, that's what I mean in the last paragraph of my previous post.

Quote:

---

Ok, I have to say I don't understand the problem.

I get DirectConnection behavior in a simple test application

---

I think OP wants a direct connection between objects living in different threads which is a Bad Thing.

Quote:

---

More likely having two properties of type QObject* and two properties of type QString.
Once all four properties are set, code is triggered that does
1) lookup of slot and signal through QMetaObject
2) call connect with the two objects and the retrieved signal and slot signatures

---

That makes sense and I will give it a try.

Quote:

---

I think OP wants a direct connection between objects living in different threads which is a Bad Thing.

---

As I stated before - all objects live in the same thread and signals are emitted/slots executed by the same thread.

---

Added after 1 30 minutes:

So I implemented DirectConnection class and it works.

Here is the header file:

Code:

---

#ifndef DIRECTCONNECTION_H
#define DIRECTCONNECTION_H
 
#include <QObject>
 
class DirectConnection : public QObject
{
    Q_OBJECT
    Q_PROPERTY(QObject* source READ getSource WRITE setSource)
    Q_PROPERTY(QObject* destination READ getDestination WRITE setDestination)
    Q_PROPERTY(QString signal READ getSignal WRITE setSignal)
    Q_PROPERTY(QString slot READ getSlot WRITE setSlot)
 
    QString _signal, _slot;
    QObject* _source;
    QObject* _destination;
    void tryConnect();
    QMetaMethod findMethod(QObject* owner, QString signature);
public:
    explicit DirectConnection(QObject *parent = 0);
    QObject* getSource();
    void setSource(QObject* source);
    QObject* getDestination();
    void setDestination(QObject* destination);
    QString getSignal();
    void setSignal(QString signal);
    QString getSlot();
    void setSlot(QString slot);
 
signals:
 
public slots:
 
};
#endif // DIRECTCONNECTION_H

---

Source file:

Code:

---

#include "directconnection.h"
#include <QMetaMethod>
 
DirectConnection::DirectConnection(QObject *parent) :
    QObject(parent), _source(NULL), _destination(NULL)
{
}
QObject* DirectConnection::getSource()
{
    return _source;
}
void DirectConnection::setSource(QObject* source)
{
    _source = source;
    tryConnect();
}
QObject* DirectConnection::getDestination()
{
    return _destination;
}
void DirectConnection::setDestination(QObject* destination)
{
    _destination = destination;
    tryConnect();
}
QString DirectConnection::getSignal()
{
    return _signal;
}
void DirectConnection::setSignal(QString signal)
{
    _signal = signal;
    tryConnect();
}
QString DirectConnection::getSlot()
{
    return _slot;
}
 
void DirectConnection::setSlot(QString slot)
{
    _slot = slot;
    tryConnect();
}
QMetaMethod DirectConnection::findMethod(QObject *owner, QString signature)
{
    const QMetaObject* metaObject = owner->metaObject();
    int index = metaObject->indexOfMethod(signature.toUtf8().constData());
    return metaObject->method(index);
}
 
void DirectConnection::tryConnect()
{
    if(_source && _destination && !_signal.isNull() && !_slot.isNull())
    {
        QMetaMethod slot = findMethod(_destination, _slot);
        QMetaMethod signal = findMethod(_source, _signal);
        QObject::connect(_source, signal,
                         _destination, slot,
                         Qt::DirectConnection);
    }
}

---

Thank you guys!