creating QML signals for C++ slots

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?

SGaist

Here is the issue: the NOTIFY keyword is a hint for the property system. It is still your duty to emit it at the adequate time.

fcarney

@mzimmers NOTIFY tells other objects what signal fires when the property changes. It does not actually fire the signal.

So in QML if the cppObject.value is bound to the "text" property of Text, the code attaches to the signal specified by the NOTIFY part of Q_PROPERTY. If the NOTIFY is not specified, it doesn't know what to attach to. You will also get warnings saying the property is non-notifiable. There is a lot going on in QML property bindings.

It is also possible for multiple Q_PROPERTY's to use the same signal if you want them all to update when one of them changes. This might be useful to sync updates.

mzimmers

@SGaist @fcarney thank you for the distinction; that makes sense now.

So, am I correct that it's best to minimize the "work" done in the QML (in my case, with this line)

onReleased: sp.value = control.value

And let the C++ code handle the rest?

And, as I mentioned earlier, this line is my only needed modification to a third-party module. Is there some way to "inject" this behavior from the QML that uses this Item?

Thanks...

fcarney

The only thing I can think of doing is having the c++ side read the initial value before the connection is made. That way they start in sync. Then, when it changes it will stay in sync as long at they are connected.