How to replace `connect(this, SIGNAL(frameSwapped())...` with modern version

8Observer8

Hello,

How to replace connect(this, SIGNAL(frameSwapped())... with modern version? I know that SIGNAL/SLOT was deprecated.

I tried to replace this:

connect(this, SIGNAL(frameSwapped()), this, SLOT(update()));

with this:

connect(this, &QOpenGLWindow::frameSwapped, this, &QOpenGLWindow::update);

error: no matching function for call to 'Window::connect(Window*, void (QOpenGLWindow::*)(), Window*, <unresolved overloaded function type>)'
         connect(this, &QOpenGLWindow::frameSwapped, this, &QOpenGLWindow::update);

Example:

empty-qopenglwindow-qt6-cpp

QT += core gui opengl widgets
win32: LIBS += -lopengl32
SOURCES += main.cpp
TARGET = app

main.cpp

/*
Build and run commands for CMD:
> qmake -makefile
> mingw32-make
> "release/app"
*/

#ifdef _WIN32
#include <windows.h>
extern "C" __declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
extern "C" __declspec(dllexport) DWORD AmdPowerXpressRequestHighPerformance = 0x00000001;
#endif

#include <iostream>

#include <QtCore/QSize>
#include <QtGui/QOpenGLFunctions>
#include <QtGui/QSurfaceFormat>
#include <QtOpenGL/QOpenGLWindow>
#include <QtWidgets/QApplication>

class Window: public QOpenGLWindow, private QOpenGLFunctions
{
public:
    Window()
    {
        resize(QSize(300, 300));
        setTitle("OpenGL 2.1, Qt6, C++");

        // Set format
        QSurfaceFormat format;
        format.setSamples(4);
        format.setSwapInterval(1);
        setFormat(format);
        connect(this, SIGNAL(frameSwapped()), this, SLOT(update()));
        // connect(this, &QOpenGLWindow::frameSwapped, this, &QOpenGLWindow::update);
    }

private:
    void initializeGL() override
    {
        initializeOpenGLFunctions();
        glClearColor(0.2, 0.2, 0.2, 1);
    }

    void paintGL() override
    {
        glClear(GL_COLOR_BUFFER_BIT);
        std::cout << "paintGL" << std::endl;
    }
};

int main(int argc, char *argv[])
{
#ifdef _WIN32
    if (AttachConsole(ATTACH_PARENT_PROCESS))
    {
        freopen("CONOUT$", "w", stdout);
        freopen("CONOUT$", "w", stderr);
    }
#endif
    std::cout << std::endl;

    QApplication app(argc, argv);
    Window w;
    w.show();
    return app.exec();
}

JonB

@8Observer8
Does your class Window need the Q_OBJECT macro in order to do signalling connections? And/or does class Window need to be defined in its own .h file so that moc can be run on it correctly?

? Offline

@8Observer8 said in How to replace `connect(this, SIGNAL(frameSwapped())...` with modern version:

I know that SIGNAL/SLOT was deprecated.

As far as I understand it's not deprecated, it's even still in use in QtQuick and QML.

JonB

@ankou29666
It certainly is "deprecated", or whatever the right word to use is, let's not get hung up on the exact word. It may be used in QtQuick/QML, and there are cases where you still need it with widgets, but for the vast majority of the time users should indeed regard it as "undesirable" and go for the newer syntax (which btw was introduced over a decade ago). There are numerous advantages to the new syntax.

? Offline

@JonB I'll hung up a little bit anyway, as far as I remember the word deprecated means that these syntax remains only for old code compatibility, and there is always another solution for new code. As far as I remember, it is used when the framework or library itself no longer make any use of these old code. and that these old syntaxes are ready to be removed from the library without breaking the library itself.

But the Qt Company still makes use of these old syntax in some cases (especially QtQuick / QML) so they can't remove it at all.

I agree with qualifying this old syntax as "unrecommended", but as far as I understand, it doesn't match the word "deprecated".
I agree that the new syntax is preferred.

JonB

@ankou29666
All fair enough. Let's agree that for OP's purpose it should be "not recommended" to use old syntax if new syntax can be used, then we are all happy :)

8Observer8

@JonB I added Q_OBJECT and #include "main.moc" but the result is the same:

main.cpp

/*
Build and run commands for CMD:
> qmake -makefile
> mingw32-make
> "release/app"
*/

#ifdef _WIN32
#include <windows.h>
extern "C" __declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
extern "C" __declspec(dllexport) DWORD AmdPowerXpressRequestHighPerformance = 0x00000001;
#endif

#include <iostream>

#include <QtCore/QSize>
#include <QtGui/QOpenGLFunctions>
#include <QtGui/QSurfaceFormat>
#include <QtOpenGL/QOpenGLWindow>
#include <QtWidgets/QApplication>

class Window: public QOpenGLWindow, private QOpenGLFunctions
{
    Q_OBJECT
public:
    Window()
    {
        resize(QSize(300, 300));
        setTitle("OpenGL 2.1, Qt6, C++");

        // Set format
        QSurfaceFormat format;
        format.setSamples(4);
        format.setSwapInterval(1);
        setFormat(format);
        // connect(this, SIGNAL(frameSwapped()), this, SLOT(update()));
        connect(this, &QOpenGLWindow::frameSwapped, this, &QOpenGLWindow::update);
    }

private:
    void initializeGL() override
    {
        initializeOpenGLFunctions();
        glClearColor(0.2, 0.2, 0.2, 1);
    }

    void paintGL() override
    {
        glClear(GL_COLOR_BUFFER_BIT);
        std::cout << "paintGL" << std::endl;
    }
};

#include "main.moc"

int main(int argc, char *argv[])
{
#ifdef _WIN32
    if (AttachConsole(ATTACH_PARENT_PROCESS))
    {
        freopen("CONOUT$", "w", stdout);
        freopen("CONOUT$", "w", stderr);
    }
#endif
    std::cout << std::endl;

    QApplication app(argc, argv);
    Window w;
    w.show();
    return app.exec();
}

JonB

@8Observer8
OK then. For all I know it's possible that this could be a case where you do need the old syntax, for some reason, but personally I would not give up yet.

I would start by trying to put in some different connect(), with new syntax, which doesn't use QOpenGLWindow methods, and see whether that goes through. What about, say

connect(this, &QObject::destroyed, this, &Window::someSlotYouAdd);

Does that go through or barf?

Hang on, let's look at the error message closely:

error: no matching function for call to 'Window::connect(Window*, void (QOpenGLWindow::*)(), Window*, <unresolved overloaded function type>)'
         connect(this, &QOpenGLWindow::frameSwapped, this, &QOpenGLWindow::update);

See the <unresolved overloaded function type>? It is the QOpenGLWindow::update that it is hiccupping on. And it will be because if you look around carefully down to QObject you will come across multiple overloads of the update() method with different parameters. You will need to use qOverload() macro or QOverload<>::of construct to specify the desired overload, see https://doc.qt.io/qt-6/qtglobal.html#qOverload etc.

? Offline

@8Observer8 you shouldn't have to include any moc file.

According to this page, the only case where the old syntax works and the new doesn't is when signal has less arguments than the slot (which will use default arguments).

But frameSwapped signal and update slot both don't take any argument ... So this is definitely not the explanation ...

JonB

@ankou29666 said in How to replace `connect(this, SIGNAL(frameSwapped())...` with modern version:

and update slot both don't take any argument

See the "Hang on" I added above. This is the cause of the OP's error message.

? Offline

@JonB when you connect with new method, and that a signal or slot was inherited from a mother class, should you use the mother or child class name ? Or is this completely indifferent ?

like connect(this, &QOpenGLWindow::frameSwapped, this, & QPaintDeviceWindow::update);

as the update slot comes from QPaintDeviceWindow ... I'm not sure but I kinda remember having some trouble this kind.

JonB

@ankou29666
I don't know, because I don't know which update() overload in the tree the OP wants to use. Your way may [well] work, I always use the qOverload() or QOverload<>::of in this case. It's useful to know anyway, because if a given class has multiple overloads of a method itself with different parameters you have to use this way anyway.

? Offline

@JonB Ok but where would that second update() overload come from ? I've looked at the whole inheritance tree the only update slot I find comes from QPaintDeviceWindow, I haven't found any update slot anywhere else ...

JonB

@ankou29666
Go to https://doc.qt.io/qt-6/qopenglwindow-members.html, press Ctrl+F, search for update. There are 3, all in QPaintDeviceWindow. With different parameters. So OP will indeed need the "overload" construct to specify which one (the one with no parameters here). BTW, the fact that only one is marked as [slot] does not affect the fact that you must specify which one for the connect().

? Offline

@JonB what I see from QPaintDeviceWindow is there are two methods (one with QRect, the other with QRegion parameter) and only one slot (without parameter) ...

JonB

@ankou29666
As I wrote:

There are 3 methods, all on that page.
Only one is marked as slot. But so what? I previously said:

BTW, the fact that only one is marked as [slot] does not affect the fact that you must specify which one for the connect().

That's why I wrote it :)

? Offline

@JonB ok I hadn't read your previous answer properly. And your last one gets me even more confused. And wondering then what's the point in declaring slots ... if you have to tell explicitly to which slot to connect ... when there's only one declared ...

Can a signal be connected to a method not declared as slot with the new syntax ? That's what I first understood from your last answer but I then had some doubts ... But when I think about it, it can connect to a lambda function which is not declared slot either ... I'm getting a little lost ...

JonB

@ankou29666
Don't panic! You may be overthinking :)

I never used the old-style connect() with strings/SIGNAL/SLOT() macros. So I cannot say whether they insisted on the slot function being marked with slot.

Yes, with the new syntax at least you can connect() to any method/function, even if it has not been declared in the slots section. I don't know if there are any cases where it has to be marked as a slot, but certainly in the normal case it does not matter. Python/PyQt might require a slot method to be @Slot decorated, not sure, but C++/moc does not. Of course it is good practice to put slots into the class's slots: section, but you don't have to.

I think the same is not true of signals. You do have to put signals into the signals: section, IIRC.

The OP's original error message reads

error: no matching function for call to 'Window::connect(Window*, void (QOpenGLWindow::*)(), Window*, <unresolved overloaded function type>)'
         connect(this, &QOpenGLWindow::frameSwapped, this, &QOpenGLWindow::update);

Now, this is a C++ compiler error message. Whatever moc might or might not have done you can see the line being presented for compilation. It has to find a match, in a parameter to connect(), for &QOpenGLWindow::update, that's all it sees. And that is ambiguous because there are 3 public methods of QOpenGlWindow::update(...) which are candidates. Whether one is or is not declared inside slots: simply has no bearing. You need to tell it which one.

The OP will need

connect(this, &QOpenGLWindow::frameSwapped, this, qOverload<>(&QOpenGLWindow::update));

Any parameters are specified inside the <>. Here that is empty so it matches the overload which takes no parameters.

In the case of the old-style code it was the SLOT(update()) which told it to pick the update() method with no parameters. Had you wished to pick one which did take parameters you would have had to specify them inside the update(...). So both ways are effectively specifying the same information, just in different formats.

jsulm

@ankou29666 said in How to replace `connect(this, SIGNAL(frameSwapped())...` with modern version:

Can a signal be connected to a method not declared as slot with the new syntax ?

Yes

"what's the point in declaring slots" - it's just a hint for developers. Any method of a class can be a slot.

? Offline

Ok I had started Qt by the times of 4.4 or so. New syntax didn't exist then. And then I didn't do any C++ until very recently. and with the old syntax it is required for a slot to be declared as such. That's what got me so troubled.
And this explains why the old syntax works when the new doesn't.

I was rather expecting the connection to be automatically matched by determining the number and types of the arguments but this is obviously not the case.