creating QML signals for C++ slots

fcarney

@mzimmers said in creating QML signals for C++ slots:

Wouldn't a signal from QML be more straightforward (if I can figure out how to do it)?

valueChanged is the signal that gets fired when the value changes. You can connect to that signal in the C++ object.

mzimmers

@fcarney said in creating QML signals for C++ slots:

valueChanged is the signal that gets fired when the value changes. You can connect to that signal in the C++ object.

I thought that valueChanged was the signal in the C++ object?

SGaist

Hi

@GrecKo said in creating QML signals for C++ slots:

// in  your C++ class:
Q_PROPERTY(float value READ value WRITE setValue NOTIFY valueChanged)
// ...

// in your QML file:
Slider {
    from: 0
    to: 100
    value: CppObject.value
    onMoved: CppObject.value = value
}

The value property of the Slider object is linked to the value property of your C++ object hence if you fire the valueChanged signal from your C++ object, the Slider object will get the notification and update its value.

fcarney

@mzimmers said in creating QML signals for C++ slots:

I thought that valueChanged was the signal in the C++ object?

It is, and it should fire when the WRITE method (setValue) is called on value. So you can use that signal with other objects on the C++ side to notify of the update.

SGaist

@fcarney said in creating QML signals for C++ slots:

@mzimmers said in creating QML signals for C++ slots:

I thought that valueChanged was the signal in the C++ object?

It is, and it should fire when the WRITE method (setValue) is called on value. So you can use that signal with other objects on the C++ side to notify of the update.

One small addition, even if it sounds obvious, don't forget to emit the signal only when there's an actual value change otherwise you will have a signal storm which is not what you want.

mzimmers

@SGaist said in creating QML signals for C++ slots:

The value property of the Slider object is linked to the value property of your C++ object hence if you fire the valueChanged signal from your C++ object, the Slider object will get the notification and update its value.

I can see that I'm doing a bad job of explaining what I'm trying to do: I want the UI to signal the app when the user manipulates the slider. Seems I need to link a signal from the QML to a slot in my C++ object.

Or...am I totally blowing this sideways?

fcarney

@SGaist said in creating QML signals for C++ slots:

// in your C++ class:
Q_PROPERTY(float value READ value WRITE setValue NOTIFY valueChanged)
// ...

// in your QML file:
Slider {
from: 0
to: 100
value: CppObject.value
onMoved: CppObject.value = value // this calls the "setValue" function of the property
}

The CppObject shown in the qml here defines a property called "value". This would be a context property or similar method of exposing a cpp object. Will be lower case on first letter as upper case context properties are not allowed. So we will now refer to it as "cppObject".

The "value" property has a signal that is fired when it changes. This is called "valueChanged". The method that calls that signal is called "setValue".

So this function might look like this:

void CppObject::setValue(float val){
    if(val == m_value) // use float fuzzy compare here
        return;
    m_value = val;
    emit valueChanged(m_value);
}

Somewhere in your cpp:
CppObject cppobject; // this object gets exposed as context property.

connect(&cppobject, &CppObject::valueChanged, [](float value){
// so something with value
});

mzimmers

I seem to still be missing a piece here. Various snippets:

main.cpp

    SliderReporter sp;
    QGuiApplication app(argc, argv);
    QQmlApplicationEngine engine;
    engine.rootContext()->setContextProperty("sp", &sp);
    engine.load(url);

sliderreporter.h

class SliderReporter : public QObject
{
    Q_OBJECT
    Q_PROPERTY(float m_value MEMBER m_value READ value WRITE setValue NOTIFY valueChanged)

public:
    explicit SliderReporter(QObject *parent = nullptr);
    float value() { return m_value; }
    void setValue (float value) { m_value = value; }
public slots:
    void reportValue(int i) {
        qDebug() << "new value of slider is:" << i;
    }
signals:
    void valueChanged(float value);
private:
    float m_value;
};

sliderreporter.cpp:

SliderReporter::SliderReporter(QObject *parent)
    : QObject{parent}
{
    QMetaObject::Connection c;
    bool b;

    c = QObject::connect(this, &SliderReporter::valueChanged, this, &SliderReporter::reportValue);
    b = static_cast<bool>(c);
    qDebug() << b;
}

and deep in my QLM code:

MouseArea {
	onReleased: sp.value = value

So, I'm performing the following (I think):

setting the context property in main.cpp
establishing the supporting methods to the property in sliderreporter.h
creating a way to "see" the signal in my SliderReporter c'tor
referencing my "sp" in my QML

What am I leaving out?

Thanks...

J.Hilk

@mzimmers

//sliderreporter.h
#ifndef SLIDERREPORTER_H
#define SLIDERREPORTER_H

#include <QObject>
#include <QDebug>

class SliderReporter : public QObject
{
    Q_OBJECT
    Q_PROPERTY(float value READ value WRITE setValue NOTIFY valueChanged)

public:
    explicit SliderReporter(QObject *parent = nullptr)
        : QObject{parent}
    {
        connect(this, &SliderReporter::valueChanged, this, &SliderReporter::onValueChanged);
    }

    [[nodiscard]] float value() const noexcept { return m_value; }
    void setValue(float newValue)
    {
        if (qFuzzyCompare(m_value , newValue))
            return;
        m_value = newValue;
        emit valueChanged(m_value);
    }

public slots:
    void setValueViaDirectCall(float value) {setValue(value);}
    /*Q_INVOKABLE <- could be added for readability, but not needed, since it is a public slot*/
    //Q_INVOKABLE void setValueViaDirectCall(float value) {setValue(value);}

    void onValueChanged(float newValue){
        qDebug() << Q_FUNC_INFO << newValue << "-:-" << value();
    }
signals:
    void valueChanged(const float &value);

private:
    float m_value;
};

#endif // SLIDERREPORTER_H

//main.cpp
#include "sliderreporter.h"

int main(int argc, char *argv[])
{
    QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
    SliderReporter sRep;
    QGuiApplication app(argc, argv);
    QQmlApplicationEngine engine;

    engine.rootContext()->setContextProperty("sRep", &sRep);

    const QUrl url(QStringLiteral("qrc:/main.qml"));
    engine.load(url);



    return app.exec();
}

//main.qml
import QtQuick 2.15
import QtQuick.Controls 2.15
import QtQuick.Window 2.15
import QtQuick.Layouts 1.15

Window {
    id: root
    width: 800
    height: 600
    visible: true

    Slider {
        from: 0
        to: 100
        value: sRep.value
        onMoved: sRep.value = value // calls setValue in your cpp file when slider handle is moved
    }

    Timer{
        running:true
        repeat: true
        interval: 5000
        onTriggered: sRep.setValueViaDirectCall(20);
    }
}

GrecKo

@J-Hilk
The same without the two unnecessary slots.

connect(this, *, this, *); is kind of a non sense most of the time. Signals and slots make sense when when you don't know where the signal will be connected. To notify a change of state to the outside. Here you can just call onValueChanged internally in the setValue (wheter there's a need to keep the two separated is left as en exercise to the reader).
Moreover exposing onValueChanged as a public slots pollutes the interface, why would you want to let the QML call it? Defining a function as slot is also not needed for the pointer to member function connect syntax. You can connect to a simple private member function (not that you should do it here).

What's the point with setValueViaDirectCall? you can do the same with property and not add additional complexity, keeping the property syntax :

onTriggered: sRep.value = 20

Sorry for being negative but we don't have to make QML integration more complicated than it is and less declarative than it should be (:

J.Hilk

@GrecKo ?

I'm not suppling production code, but a simple example that shows the different ways one can achieve the OP's desired outcome.

connect(this, *, this, *); is kind of a non sense most of the time. Signals and slots make sense when when you don't know where the signal will be connected. To notify a change of state to the outside. Here you can just call onValueChanged internally in the setValue (wheter there's a need to keep the two separated is left as en exercise to the reader).

I whole hardly disagree, Property setters should do nothing but set a property and emit a signal. The c++ reaction to that changed signal can than be done in slot, that can, but doesn't have to be in the same class.

I for example usually have one base class that contains all Properties, and one derived one, that contains the logic.

Moreover exposing onValueChanged as a public slots pollutes the interface, why would you want to let the QML call it?

I was to lazy to add the additional private, my bad.

Defining a function as slot is also not needed for the pointer to member function connect syntax.

I'm aware, but it (the intend) is still more readable, imho

What's the point with setValueViaDirectCall? you can do the same with property and not add additional complexity, keeping the property syntax :

onTriggered: sRep.value = 20

again, showing an alternative.

mzimmers

Thanks for the replies, guys. I had to re-read the docs a few times to really understand what I was missing - it was an explicit call to emit() in my setValue() function. It now works more or less as I hoped.

A few wrap-up questions, please:

if I do have to explicitly emit my setValue(), what is the purpose of its mention in the Q_PROPERTY macro?
if I wanted to emit the signal from QML, can I change my QML statement:

MouseArea {
    id: trackMouse
    onReleased: sp.value = control.value
}

to something more like:

MouseArea {
    id: trackMouse
    onReleased {
        sp.value = control.value
        emit sp.valueChanged
    }
}

What's the correct syntax to do something like this? And, is it even a good idea to emit the signal from QML, or should I go ahead and do it per @J-Hilk's example?
3. The above passage is the only modification I have to make to a third-party module. It would be nice to keep this module unmodified. Is there any way I can give trackMouse this property from outside the module?

Thank you...

Bob64

@mzimmers "if I do have to explicitly emit my setValue(), what is the purpose of its mention in the Q_PROPERTY macro?"

The Q_PROPERTY macro is what gathers together the bits of your class interface that contribute to that property's implementation. Yes, you have to do the work to emit the signal so that there is a notification being generated, but unless you declare it in the macro, there is nothing to tell Qt that this particular signal is the one associated with that property change. Although regular naming conventions are usually used, Qt itself does not infer anything from the name. You could call the signal whatever you want.

mzimmers

@Bob64 I'm not sure I fully understand your answer - to me, it sounds like including NOTIFY is merely bookkeeping. How (if at all) does it change the behavior of the program?

Thanks...

fcarney

@mzimmers said in creating QML signals for C++ slots:

How (if at all) does it change the behavior of the program?

It is how everything in QML gets notified when a value changes. So if you did the following:

Text {
  text: sp.value
}

If the signal is not in the property definition "text" will never get updated. Every binding to every property in QML works this way.

mzimmers

@fcarney OK, but then, why doesn't the signal fire automatically from this line?

            onReleased: sp.value = control.value

fcarney

@mzimmers If the value is not changed it won't fire. The initial value will be read at some point. Then it will only fire if it changes.

I am thinking you want some other behavior in your code. What do you want to happen? Ignore the code. Are you wanting to log data periodically?

mzimmers

@fcarney said in creating QML signals for C++ slots:

@mzimmers If the value is not changed it won't fire. The initial value will be read at some point. Then it will only fire if it changes.

But when I manipulate the slider through the GUI, this signal never seems to fire. I do get the call to the setValue() function.

I am thinking you want some other behavior in your code. What do you want to happen? Ignore the code. Are you wanting to log data periodically?

No, I'm more just trying to remind myself/better understand how this mechanism works. I'll be using a lot of it in this upcoming project, and I want to get it down cold. I'm still confused on what causes the property signal to fire, as in my example, it doesn't happen merely by changing the value of the property.

fcarney

main.cpp:

#include <QGuiApplication>
#include <QQmlApplicationEngine>
#include <QQmlContext>
#include <QDebug>

#include "cppobject.h"

int main(int argc, char *argv[])
{
#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
    QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
#endif

    QGuiApplication app(argc, argv);

    CppObject cppobject;

    QQmlApplicationEngine engine;

    engine.rootContext()->setContextProperty("cppObject", &cppobject);

    // some connection to some object
    cppobject.connect(&cppobject, &CppObject::valueChanged, [](float value){
        qDebug() << "cppObject.value changed:" << value;
    });

    const QUrl url(QStringLiteral("qrc:/main.qml"));
    QObject::connect(&engine, &QQmlApplicationEngine::objectCreated,
                     &app, [url](QObject *obj, const QUrl &objUrl) {
        if (!obj && url == objUrl)
            QCoreApplication::exit(-1);
    }, Qt::QueuedConnection);
    engine.load(url);

    return app.exec();
}

main.qml:

import QtQuick 2.15
import QtQuick.Window 2.15
import QtQuick.Controls 2.15
import QtQuick.Layouts 1.15

Window {
    width: 640
    height: 480
    visible: true
    title: qsTr("Hello World")

    ColumnLayout {


        Slider {
            Layout.minimumWidth: 500
            Layout.minimumHeight: 50

            value: cppObject.value

            onValueChanged: {
                cppObject.value = value
            }
        }

        Text {
            text: cppObject.value
        }

    }
}

cppobject.h:

#ifndef CPPOBJECT_H
#define CPPOBJECT_H

#include <QObject>

class CppObject : public QObject
{
    Q_OBJECT

    Q_PROPERTY(float value READ value WRITE setValue NOTIFY valueChanged)

    float m_value;

public:
    CppObject()
        : m_value(0)
    {}

    float value() const;
    void setValue(float newValue);
signals:
    void valueChanged(float value);
};

inline float CppObject::value() const
{
    return m_value;
}

inline void CppObject::setValue(float newValue)
{
    if (qFuzzyCompare(m_value, newValue))
        return;
    m_value = newValue;
    emit valueChanged(newValue);
}

#endif // CPPOBJECT_H

You can see the affect without the signal by running with it commented out.
For demonstration I hooked a lambda to the signal of cppobject in main.cpp.
This was tested in Qt 5.15.2.

mzimmers

@fcarney thanks for the code sample. I didn't try it, because I'm sure it works.

I'm still not getting something: why does setValue have to emit the signal if the NOTIFY property is supposed to cause this to happen automatically when the value changes?